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I.  INTRODUCTION 


A.  PROBLEM  STATEMENT 

1.  Description 

Communication  is  the  essence  of  command  and  control  (C2),  and  the  availability 
of  real-time,  text-based  communications  tools  has  led  to  a  proliferation  of  ad  hoc 
“solutions”  for  the  warfighter.  Currently  within  the  services,  every  command  appears  to 
have  its  own  preferred  text-based  chat  client.  While  these  solutions  fill  short  tenn 
requirements,  they  usually  miss  the  mark  of  joint  interoperability.  Lack  of  a  standardized 
text  chat  tool  for  C2  has  led  to  confusion  and  an  inability  to  interoperate.  No  official 
text-based  chat  requirements  document  exists  for  any  of  the  services  nor  is  there  an 
official  joint  chat  requirements  document.  Further,  there  is  no  official  support  for  text- 
based  chat  from  the  services’  program  offices.  In  effect,  within  the  U.S  military  there  is  a 
tool  used  extensively  for  C2  with  no  official  requirements,  no  official  support,  and  no 
official  sponsorship. 

This  thesis  first  assesses  the  impact  of  synchronous  (real-time),  text-based  chat  on 
military  C2  processes.  Operational  chat  usage  is  documented  across  the  warfighting 
functions  and  the  full  spectrum  of  military  operations  with  a  brief  selection  of  use  cases. 
The  current  trend  in  chat  research  focuses  on  the  technical  aspects  of  chat  based  on 
anecdotal  evidence,  both  of  which  obscure  development  of  a  coherent  problem  statement. 
This  research  consolidates  specific  cases  of  chat  use  to  better  develop  insight  into  the 
problem,  catalog  capability  gaps,  and  generate  high-level  requirements. 

There  is  risk  associated  with  various  chat  tools  and  protocols.  These  technical 
risks  are  well  documented  by  organizations  like  the  Defense  Infonnation  Systems 
Agency  (DISA).  In  this  paper,  we  assess  not  only  technical  risks,  but  other  risks  that  are 
very  difficult  to  quantify,  like  those  related  to  organization,  human  factors,  doctrine,  and 
perhaps  most  interestingly,  the  impact  of  chat  use  on  other  C2  methods. 

We  finish  with  a  framework  for  documenting  current  and  developing  future  high- 
level  chat  requirements.  These  high-level  requirements  decompose  the  chat  problem  to  a 
level  that  users,  engineers,  and  managers  alike  can  use  and  understand.  From  this 
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common  understanding  all  stakeholders  can  work  together  to  develop  a  set  of  combined 
and  joint,  text-based  chat  requirements  for  the  next-generation  C2  systems. 

2.  Background 

Modern  chat  tools  allow  multiple,  concurrent  users  real-time  participation  in 
multiple  chat  channels  (chat  rooms).  The  conversations  within  these  channels  are 
referred  to  as  threads.  The  use  of  client-server  architecture  provides  the  ability  to  scale  a 
population  of  users  from  a  few  locally  to  thousands  globally.  Internet  Relay  Chat  (IRC) 
is  one  of  the  most  widely  used  chat  protocols  for  military  C2  (Boettcher  2005;  Duffy 
2005).  This  study  considers  chat  usage  regardless  of  type,  whether  chat  specific  tools 
like  mIRC  or  Microsoft  Chat  (MS  Chat)  or  embedded  chat  functionality  found  in  many 
C2  systems  and  collaborative  suites  like  InfoWorkSpace  (IWS). 

Chat  use  by  the  military  grew  rapidly  during  Operation  Enduring  Freedom  (OEF) 
and  Operation  Iraqi  Freedom  (OIF).  Not  only  did  chat  usage  grow  on  its  own,  we  saw 
chat  usage  grow  to  supplement  (or  in  some  cases  replace)  other  C2  systems.  The 
experiences  of  the  United  State  Navy  and  the  United  States  Central  Command 
(USCENTCOM)  illustrate  this. 

Early  during  OEF  there  was  one  IRC  server  in  the  Navy’s  Fifth  Fleet  that 
averaged  300  concurrent  chat  users  (Banerjee  2005).  Chat  use  soon  overcame  capacity 
and  a  second  IRC  server  was  installed  in  Fifth  Fleet  supporting  approximately  500 
concurrent  users  (Banerjee  2005).  Chat  use  grew  drastically  during  OIF  and  two  more 
IRC  servers  were  installed,  bringing  the  total  to  four  servers  supporting  approximately 
2500-3000  concurrent  users  in  350-400  chat  channels  (Banerjee  2005;  Heacox,  Moore, 
Morrison,  and  Yturralde  2004).  Figure  1  shows  the  number  of  chat  users  and  chat  rooms 
on  the  Fifth  Fleet  servers  by  date  from  buildup  through  the  start  of  combat  operations. 
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Figure  1 .  IRC  use  prior  to  and  during  OIF;  bps/user  =  bits  per  second  per  user  (From: 

Bentrup,  Banerjee,  Baldwin,  and  Kimble  2005) 

Prior  to  OIF,  USCENTCOM  used  the  Defense  Collaborative  Tool  Suite  (DCTS) 
chat  programs  during  exercises  in  Saudi  Arabia;  however,  DCTS  provided  inadequate 
chat  capability  (no  multiple  room  support)  and  USCENTCOM  J6  made  the  switch  to 
IWS  (Jara  and  Lisowski  2003).  The  bandwidth  requirements  of  chat  with  IWS  created 
latency  problems  and  USCENTCOM  switched  to  the  US  Naval  Forces  Central 
Command’s  (USNAVCENT)  four  IRC  servers  in  Bahrain,  which  continue  supporting  all 
areas  of  operations  (Banerjee  2005;  Jara  and  Lisowski  2003).  Currently  servers  at 
USNAVCENT,  A1  Udeid  Airbase  in  Qatar,  Headquarters  USCENTCOM,  and  DISA 
support  the  following  chat  clients:  mIRC,  MS  Chat,  JABBER,  and  Internet  Explorer  Web 
Browser  clients  (Moore  2005). 

Users  rapidly  realized  text  chat  was  a  mission  essential  C2  tool  and  discussion 
grew  about  the  lack  of  official  requirements,  official  support,  and  official  sponsorship. 
Within  the  Department  of  the  Navy,  the  Navy’s  program  office,  Space  and  Naval 
Warfare  Command  (SPAWAR)  reacted  first.  In  response  to  the  Navy’s  text  chat  needs, 
Joint  Distributed  Command  and  Control  Technologies,  SPAWAR  Systems  Center  San 
Diego  (SSC-SD)  hosted  the  1st  Annual  Internet  Relay  Chat  Conference  in  2004.  All  four 
services,  numerous  Combatant  Commands  (COCOMs),  and  Other  Government  Agencies 

(OGAs)  attended.  The  conference’s  purpose  was  to  identify  chat  users  and  provide 
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support  to  them  throughout  the  Department  of  Defense  (DOD).  While  focused  on  IRC 
protocol-based  chat  tools,  this  conference  supported  users  of  all  chat  tools  and  discussed 
emerging  technologies  and  the  way  forward  within  DOD.  The  2nd  Annual  IRC 
Conference  was  held  in  June  2005  and  was  again  attended  by  all  four  services,  numerous 
COCOMs,  and  OGAs. 

During  the  June  2005  conference,  Joint  Distributed  Command  and  Control 
Technologies  SSC-SD  was  tasked  with  developing  the  joint  chat  requirements  for  a  Joint 
Resource  Oversight  Council  (JROC)  package  by  Joint  Chiefs  of  Staff  J-6  (JCS-J6)  and 
Office  of  the  Assistant  Secretary  of  Defense  for  Networks  and  Infonnation  Integration 
(ASD  (Nil)).  This  research  is  part  of  that  effort. 

3.  Research  Questions 

This  thesis  addressed  four  research  questions: 

a.  How  is  chat  used  across  the  services  and  warfighting  functions? 

b.  Why  is  chat  used  across  the  services  and  warfighting  functions? 

c.  What  risks  are  associated  with  chat  use? 

d.  What  are  the  high  level  chat  requirements? 

B.  OBJECTIVES 

The  seven  objectives  developed  to  answer  the  research  questions  were: 

1.  Document  chat  use  cases  across  the  services,  including  COCOMs,  coalition 
partners,  and  OGAs.  Use  the  joint  warfighting  functions  and  joint  /  combined  doctrine  as 
the  framework  guiding  collection,  analysis,  and  presentation  of  the  use  cases. 

2.  Document  the  reasons  for  warfighter  chat  use  across  the  same  agencies  listed 
in  objective  one.  Collect,  analyze,  reduce,  and  report  the  attributes  used  by  warfighters  to 
communicate  why  they  used  chat. 

3.  Introduce  the  more  difficult  to  quantify  risks  associated  with  the  integrity, 
confidentiality,  and  availability  of  chat  and  the  effects  of  chat  use  on  tactical  infonnation 
exchange  and  situational  awareness. 

4.  Consolidate  the  services’  explicitly  stated  chat  requirements  contained  in 

numerous  reports,  briefings,  emails,  capabilities  documents,  etc. 
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5.  Consolidate  selected  COCOM  explicit  chat  requirements  contained  in 
numerous  reports,  briefings,  emails,  capabilities  documents,  etc. 

6.  Develop  a  framework  for  chat  requirements  development  that  decomposes  the 
chat  problem  to  a  level  that  users,  engineers,  and  managers  alike  can  use  and  understand. 

7.  Define  avenues  for  future  research  that  support  the  further  development  and 
decomposition  of  combined  and  joint,  text-based  chat  requirements  for  the  next- 
generation  C2  systems. 

C.  SCOPE  AND  LIMITATIONS 

This  thesis  was  limited  to  the  following  major  tasks:  consolidate  the  available, 
disparate  information;  develop  the  joint  chat  requirements;  and  evaluate  the  TRIDENT 
WARRIOR  (TW05)  results.  The  literature  review  was  limited  to  documenting  the 
concepts  driving  military  C2  towards  real-time  collaboration.  Requirements  development 
was  limited  to  problem  definition  and  development  of  a  high-level  requirements 
framework  for  future  chat  /  C2  tool  development.  This  thesis  limited  the  technical  review 
of  chat  protocols,  chat  tools,  and  chat  architectures  to  what  supported  the  research 
questions  and  the  experimentation. 

D.  THESIS  ORGANIZATION 

Chapter  II  surveys  the  joint  and  service  concepts  driving  the  evolution  of  C2, 
doctrine,  and  defense  acquisition.  Chapter  III  provides  the  methodology  for  data 
collection,  analysis,  and  experimentation.  The  chat  use  cases,  reasons  for  chat  use,  chat 
risks,  and  chat  requirements  are  reported  in  Chapter  IV.  Chapter  V  presents  opportunities 
for  future  research  and  concludes. 


5 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


6 


II.  LITERATURE  REVIEW 


No  single  body  of  work  defines  text-based  chat  usage  for  military  C2,  making  a 
significant,  top  down  literature  review  necessary.  The  evolutions  in  joint  force  doctrine 
and  current  operations  drive  the  changes  in  military  C2  that  create  capability  gaps  leading 
to  the  surge  in  chat  use.  This  review  starts  with  the  doctrine  driving  the  development  of 
the  future  joint  force  and  subsequent  transformation  of  the  services.  Continuing  to  drill 
down,  we  look  at  the  service  visions,  their  transformation  roadmaps,  and  their  technology 
enablers  for  providing  the  necessary  C2  capabilities  to  operate  as  part  of  the  future  joint 
force.  Finally,  we  study  the  small  body  of  unclassified  research  focused  on  military  chat 
use.  This  work  is  grouped  in  three  categories:  technical,  human  systems  integration 
(HSI)  and  a  key  piece  on  the  risks  associated  with  chat. 

A.  FUTURE  JOINT  WARFARE 

The  DOD’s  Capabilities-Based  Assessment  (CBA)  process  bridges  strategic 
guidance  and  future  joint  force  capabilities,  and  the  Joint  Operations  Concepts  (JOpsC) 
family  of  concepts  is  the  result.  The  goal  is  to  design,  from  the  ground  up,  a  future  joint 
force  that  is  fully  integrated,  expeditionary,  networked,  decentralized,  adaptable,  lethal, 
and  possesses  decision  superiority  (JCS  J7  2006). 

The  JOpsC  is  a  hierarchy  of  living  documents  based  upon  both  future  vision  and 
lessons  learned  from  current  operations.  They  are  the  doctrinal  framework  for  future  full- 
range  military  operations  (JCS  J7  2006).  Services  and  other  defense  agencies  develop  the 
Doctrine,  Organization,  Training,  Material,  Leadership  and  Education,  Personnel  and 
Facilities  (DOTMLPF)  solutions  to  achieve  the  capabilities  enumerated  in  the  JOpsC. 
Service  and  joint  experimentation  evaluate  these  capabilities  and  their  ability  to  support 
decisive  operations  across  the  full  military  spectrum.  Figure  2  depicts  the  JOpsC 
hierarchy. 
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Joint  Operations  Concepts 


Figure  2.  Joint  Operations  Concepts  (JOpsC)  Hierarchy  (From:  CJCS  2004) 


The  JOpsC  play  a  central  role  in  the  Joint  Capabilities  Integration  &  Development 
System  (JCIDS)  and  support  the  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  and  the 
JROC  in  assessing  and  prioritizing  joint  military  capability  needs  (CJCS  2005).  The 
JOpsC  guide  the  functional  capability  analyses  that  are  captured  in  the  capability 
documents  required  for  Milestone  Decisions  in  defense  acquisition  projects.  This  process 
is  captured  in  Figure  3  (“Family  of  Joint  Future  Concepts”  refers  to  the  JOpsC). 
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1.  The  Capstone  Concept  for  Joint  Operations 

The  Capstone  Concept  for  Joint  Operations  (CCJO)  (2005)  is  the  DOD’s  capstone 
concept  for  future  joint  warfare.  The  CCJO  provides  the  broad  outline  of  how  the  future 
joint  force  will  operate  and  the  subordinate  Joint  Operational  Concepts  (JOCs)  and  the 
services’  concepts  expand  upon  the  CCJO  guidance.  The  CCJO  (2005)  calls  for  joint 
forces  to  interoperate  and  share,  collaborate,  coordinate  maneuver,  and  integrate 
situational  awareness.  These  concepts  seek  to  create  a  knowledge-empowered  force  that 
makes  better,  faster  decisions  at  all  levels  and  increases  joint  force  effectiveness  (CCJO 
2005). 

The  concepts  the  CCJO  sets  forth  require  significant  evolution  in  joint  C2.  Of 
particular  note,  the  CCJO  (2005)  defines  lethality  as  “the  ability  to  leverage  technology  to 
destroy  the  adversary  and/or  his  systems  at  range  or  in  close  combat.”  This  sets  the  stage 
for  interim  capability  gaps  in  current  C2  systems  that  are  being  plugged  with  text  chat. 

2.  Joint  Operating  Concepts 

The  four  JOCs  address  the  environments,  the  challenges,  and  the  evolution  in 
DOTMLPF  required  for  the  future  joint  force  to  operate  across  the  full  spectrum  of 
military  operations.  The  JOCs  are  summarized  in  Table  1. 


Table  1. 

Joint  Operating  Concept 

Joint  Operating  Concepts  Summary 

Summary 

Major  Combat  Operations 

Establishes  the  framework  for  transitioning  the  armed  forces  from  the 
industrial  age  to  the  technology  age  with  emphasis  on  conducting  large- 
scale  military  actions  in  a  distributed,  collaborative  environment. 

Homeland  Defense  and  Civil 
Support 

How  DOD  intends  to  perform  its  responsibilities  associated  with 
securing  the  Homeland,  to  include  Homeland  Defense  (HLD),  Civil 
Support  (CS),  and  Emergency  Preparedness  (EP)  in  the  2015  timeframe. 

Strategic  Deterrence 

How  Joint  Force  Commanders  will  plan,  prepare,  deploy,  employ,  and 
sustain  a  joint  force  to  contribute  to  a  strategic  deterrence  strategy  set 
forth  by  national  leadership  through  2015. 

Stability  Operations:  Military 
Support  to  Security, 
Transition  & 
Reconstruction 

"The  joint  force,  as  part  of  a  multinational  and  integrated,  multi-agency 
operation,  will  provide  security,  initial  humanitarian  assistance,  limited 
governance,  restoration  of  essential  public  services,  and  other 
reconstruction  assistance.” 

Sources:  (Major  Combat  Operations  Joint  Operating  Concept  2004;  Homeland  Defense  and 
Civil  Support  Joint  Operating  Concept  2005;  Strategic  Deterrence  Joint  Operating  Concept  2004; 
Stability  Operations:  Military  Support  to  Security,  Transition,  and  Reconstruction  Joint  Operating 

Concept  2004) 
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Each  JOC  lists  robust  future  C2  requirements;  however,  these  requirements  are 
needed  by  today’s  commanders.  A  brief  examination  of  these  requirements  helps  explain 
the  origin  of  capability  gaps  in  today’s  military  C2  systems. 

The  Major  Combat  Operations  Joint  Operating  Concept  (MCO  JOC)  (2004) 
declares  the  rapid  advance  and  proliferation  of  “information  age”  technologies  require 
fundamental  changes  in  how  we  approach  warfare  and  conflict  resolution.  For  achieving 
this  central  theme  the  MCO  JOC  (2004)  states: 

Decisive  conclusions  are  enabled  by  the  fluid  and  coherent  application  of 
joint  military  action  in  conjunction  with  interagency  and  coalition  power, 
using  an  effects-based  approach  and  leveraging  pervasive  knowledge  in  a 
networked  environment  to  increase  levels  of  collaboration,  precision,  unity 
of  purpose  and  coherency  in  action. 

The  Homeland  Defense  and  Civil  Support  Operating  Concept  (HLD  CS  JOC)  has 
eight  enabling  capabilities.  Four  of  these  capabilities  listed  in  the  HLD  CS  JOC  (2005) 
are  supported  by  chat: 

•  Ensure  a  collaborative  and  interoperable  DOD  and  interagency  partner 
unity  of  effort  against  threats  to  the  Homeland,  to  include  consequence 
management  operations 

•  Develop  and  maintain  situational  awareness  and  shared  understanding 
throughout  the  HLD/CS/EP  environments 

•  Develop  and  maintain  a  robust,  redundant,  secure,  decentralized, 
distributed,  collaborative,  and  interoperable  command,  control, 
communications,  computers,  and  intelligence  (C4I)  system  and  process 

•  Develop  and  maintain  robust  interagency  coordination  to  include 
communications  interoperability,  intelligence  sharing,  and 
policies/procedures  on  entrance  and  exit  strategies  for  DOD  involvement 

The  Strategic  Deterrence  Joint  Operating  Concept  (SD  JOC)  (2004)  defines  two 
key  capabilities:  global  situational  awareness  and  robust  global  C2.  Global  situational 
awareness  involves  gathering  intelligence  required  for  deterrence  operations.  This 
requires  persistent  intelligence,  surveillance,  and  reconnaissance  (ISR)  efforts  in  a 
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collaborative  environment.  Global  C2  calls  for  a  horizontally  and  vertically  integrated 
distributed  network  to  provide  key  leadership  with  an  effective  and  survivable  command 
and  control  capability  (SD  JOC  2004).  This  C2  capability  must  gracefully  degrade  to  a 
small,  but  absolutely  reliable  channel. 

The  Stability  Operations:  Military  Support  to  Security,  Transition  & 
Reconstruction  Joint  Operating  Concept  (SO  JOC)  is  particularly  relevant  to  OEF  and 
OIF.  This  JOC  lists  numerous  C2  and  battlespace  awareness  capabilities  required  for 
success.  Table  2  summarizes  those  capabilities  required  in  OEF  and  OIF  that  drive  chat 
use. 


Table  2.  SO  JOC  Capabilities  Driving  Chat  Use  in  OEF  and  OIF 

Command  and  Control  Battlespace  Awareness 


—  The  ability  to  conduct  collaborative, 
planning,  execution,  and  information  sharing 
among  US  civil-military  agencies  and 
coalition  partners  from  the  operational  to 
tactical  levels. 

—  The  ability  to  achieve  multi-agency 
coherency  of  action  during  planning, 
coordination,  and  execution  by  creating  a 
joint,  and  combined  when  necessary,  multi¬ 
agency  planning  and  execution  organization 
empowered  to  facilitate  integrated  civil- 
military  operations. 

—  The  ability  to  enhance  rapid  information 
sharing  with  coalition  members,  multi¬ 
agency  players,  and  non-governmental 
organizations  through  information  sharing 
technologies  and  policies. 

—  The  ability  to  field  a  command  and  control 
system  with  reach  back  capability  and 
connectivity  to  facilitate  other  agency 
participation. 


—  The  ability  to  achieve  a  persistent 
situational  awareness  and  shared 
understanding  in  a  joint,  multi-agency,  and 
multinational  context  in  order  to  know  the 
operational  environment  and  the 
interrelationship  among  ourselves,  our 
adversaries,  and  the  local  population. 

—  The  ability  to  use  an  operational  net 
assessment  to  support  stability  operations 
and  to  reflect  that  information  in  the 
integrated  civil-military  common  relevant 
operating  picture. 

The  ability  to  provide  persistent 
intelligence,  surveillance  and  reconnaissance 
that  integrates  all  intelligence  capabilities, 
including  human  intelligence  assets,  into  the 
overall  intelligence,  surveillance,  and 
reconnaissance  architecture. 


Source:  (Stability  Operations:  Military  Support  to  Security,  Transition,  and 
Reconstruction  Joint  Operating  Concept  2004) 


These  JOCs  list  numerous  C2  and  battlespace  awareness  capabilities  required  for 
the  future  joint  forces  to  conduct  operations  across  the  full  military  spectrum.  They  rely 
heavily  upon  joint  force  connectivity  throughout  the  battlespace  to  facilitate  vertical  and 
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horizontal  collaboration  during  all  operational  phases  across  the  spectrum  of  military 
operations.  The  current  Global  War  on  Terrorism  (GWOT)  is  the  type  of  complex 
conflict  envisioned  for  the  future  joint  force.  With  the  current  joint  force  already  fighting 
the  “future”  conflict,  we  can  see  gaps  empirically  in  current  C2  systems  that  have  our 
warfighters  looking  for  ad  hoc  solutions  like  text  chat. 

3.  Joint  Functional  Concepts 

The  Joint  Functional  Concepts  (JFC)  broadly  addresses  their  respective  functional 
areas  across  the  range  of  military  operations.  The  three  impacting  C2  are:  Net-Centric 
Environment  (NC  JFC),  Command  and  Control  (C2  JFC),  and  Battlespace  Awareness 
(BA  JFC).  These  three  have  direct  impact  on  contemporary  C2  issues  and  are  driving 
future  C2  development.  The  NC  JFC,  C2  JFC,  and  BA  JFC  are  summarized  in  Table  3. 


Table  3.  Select  Joint  Functional  Capability  Summary 


Joint  Functional  Summary 

Concept 

Net-Centric 

Environment 

“ The  Net-Centric  Environment  is  a  framework  for  full  human  and  technical 
connectivity  and  interoperability  that  allows  all  DOD  users  and  mission  partners 
to  share  the  information  they  need,  when  they  need  it,  in  a  form  they  can 
understand  and  act  on  with  confidence,  and  protects  information  from  those  who 
should  not  have  it.  ” 

Command  and 
Control 

“In  2015  Joint  C2  will  be  a  joint  decision-making  process  that  is  dynamic, 
decentralized,  distributed,  deployable,  and  highly  adaptive.  Enabled  by  a  robust, 
secure,  integrated  network,  and  through  the  employment  of  collaborative 
information  environments,  the  Joint  Force  Commander  will  possess  a  seamless, 
deployable  command  and  control  capability’.  ” 

Battlespace 

Awareness 

"Battlespace  Awareness  in  2015  provides  actionable  intelligence  to  commanders 
and  warfighters.  This  capability’,  enabled  by  a  thorough  understanding  of  the 
battlespace  focusing  on  the  adversary’  and  other  relevant  factors,  brings  to  bear  a 
responsive  system-of-systems  fully  integrating  personnel,  documents,  equipment, 
and  technical  means  in  providing  persistent,  redundant,  and  tailored  coverage.  ” 

Sources:  (Net-Centric  Environment  Joint  Functional  Concept  2005;  Joint  Command  and 
Control  Functional  Concept  2004;  Functional  Concept  for  Battlespace  Awareness  2003) 


4.  Joint  Integrating  Concepts 

The  Joint  Integrating  Concepts  (JICs)  address  specific  military  problems  within 
the  broad  functional  areas  of  the  JFCs.  The  two  impacting  C2  are:  Command  and 
Control  (C2  JIC)  and  Net-Centric  Operating  Environment  (NC  JIC).  These  JICs  address 
the  required  tasks  and  standards  within  the  functional  areas.  This  lends  them  to 
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identification,  assessment,  and  analysis  of  capability  gaps  and  solutions.  The  C2  JIC  and 
NC  JIC  are  summarized  in  Table  4. 


Table  4.  Select  Joint  Integrating  Concept  Summary 


Joint  Integrating 
Concept 

Summary 

Command  and 
Control 

“This  Joint  Integrating  Concept  (JIC)  promotes  the  development  of  C2  capabilities 
for  agile,  decisive,  and  integrated  force  employment  in  all  phases  of  combat  and 
supporting  operations,  as  required  by  the  National  Military  Strategy’.  ” 

Net-Centric 

Environment 

“ The  concept’s  central  idea  is  that,  for  the  future  Joint  Force  to  achieve  decisive 
levels  of  shared  knowledge  and  technical  connectivity,  the  NCOE  must  provide  the 
Joint  Force  with  pervasive  knowledge  through  the  full  integration  of  knowledge 
management(KM),  network  management  (NM),  and  information  assurance  (IA).  ” 

Sources:  (Command  and  Control  Joint  Integrating  Concept  2005;  Net-Centric  Operational 
Environment  Joint  Integrating  Concept  2005) 


B.  SERVICE  VISIONS  AND  TRANSFORMATION 

The  service  visions,  transformation  plans,  and  technology  enablers  focus,  like  the 
JOpsC,  on  leveraging  technology  to  destroy  the  adversary.  They  are  listed  by  service  in 
Table  5  and  then  discussed  by  service  in  the  following  sections. 


Table  5.  Vision,  Transformation,  and  Technology  Doctrine  by  Service 


Service 

Vision 

Transformation 

Technology 

US  Army 

FM:  1  The  Army 

Army  Transformation 
Roadmap 

LANDWARNET 

US  Air  Force 

America's  Air  Force 
Vision  2020 

U.S.  Air  Force 
Transformation  Flight 
Plan  2004 

Command  and  Control 
(C2)  Constellation 

Naval  Transformation 
Roadmap  2003 

FORCEnet:  A 

US  Navy 

Sea  Power  21 

Functional  Concept  for 
the  21st  Century 

US  Marine  Corps 

Strategy  21 

Marine  Capstone 
Concepts 

Marine  Air  Ground 
Task  Force  Command 
and  Control 

1.  United  States  Army 

a.  Field  Manual  1:  The  Army 

Field  Manual  (FM)  1 :  The  Army  (2005)  establishes  the  principles  for  land 
power  employment  that  drive  Anny  doctrine  and  looks  at  Anny  contributions  to  the 
future  joint  force.  This  vision  also  sets  forth  Mission  Command  as  the  Army’s  preferred 
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C2  method.  Mission  Command  implementation  is  supported  by  two  components  of  the 
Army  Vision:  integrating  component  technology  of  future  combat  systems  and 
developing  networked  information  systems.  The  integration  component  includes  sensors, 
information  systems,  and  manned  and  unmanned  vehicles  to  improve  commanders’ 
situational  awareness  (SA).  The  networked  component  is  a  family  of  networked  land  and 
airborne  maneuver  and  supporting  systems  built  around  the  soldier. 

b.  Army  Transformation  Roadmap 

The  2004  Anny  Transformation  Roadmap  (2004)  explains  how  the  Army 
will  maintain  current  capabilities  while  developing  new  capabilities  required  for  the 
future  joint  force.  The  Army  intends  its  Future  Combat  Systems  (FCS)  to  achieve  the 
integration  of  component  technology  of  future  combat  systems  and  development  of 
networked  information  systems  called  for  in  FM1.  Finally,  the  Army’s  roadmap  sets 
forth  LandWarNet  for  tying  together  its  FCS  equipped  forces  and  integrating  them  into 
the  Global  Information  Grid  (GIG). 

c.  LANDWARNET 

The  Anny  LandWarNet  literature  consists  primarily  of  a  collection  of 
presentations,  reports,  and  briefs.  The  Army  Chief  Information  Officer  (CIO)/G-6  and 
the  Army  Training  and  Doctrine  Command  (TRADOC)  are  developing  the 
LANDWARNET  concept  with  Network  Enterprise  Technology  Command 
(NETCOM)/9th  Army  Signal  Command  (Public  Affairs  Guidance  (PAG)  on  Army  Focus 
Area,  The  Network  2005).  LandWarNet  is  the  Anny  Enterprise  Network,  its  portion  of 
the  GIG,  providing  networks  to  the  Active  Component  forces,  National  Guard,  Army 
Reserve,  and  sustaining  bases  (LANDWARNET:  Network  Strategy  for  Land  Combat 
2004).  Three  intenelated,  integrated,  and  interactive  domains  comprise 
LANDWARNET:  communications,  computing  infrastructure,  and  core  enterprise 
services  (Public  Affairs  Guidance  (PAG)  on  Army  Focus  Area,  The  Network  2005). 

2.  United  States  Air  Force 

a.  America ’s  Air  Force  Vision  2020 

America’s  Air  Force  Vision  2020  (2000)  envisions  a  future  aerospace 
force  whose  contributions  to  the  future  joint  force  are  based  on  its  technological  and 
operational  developments  that  increase  its  combat  capability.  The  C2  challenges  of  this 
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future  aerospace  force  stem  from  the  required  global  integration  of  distributed  space, 
airborne,  and  land  components  with  infonnation  operations  (10). 

b.  U.S.  Air  Force  Transformation  Flight  Plan  2004  (Flight  Plan) 

Flight  Plan  (2004)  is  how  the  Air  Force  is  transforming  and  developing  its 

military  capabilities,  with  emphasis  on  joint  and  coalition  warfighting  enablers,  as  part  of 
the  future  joint  force.  Appendix  D  details  Flight  Plan  support  to  the  required  JOpsC 
capabilities.  Flight  Plan  focuses  on  a  methodology  for  Air  Force  transformation  rather 
than  specifics.  There  is  emphasis  on  the  role  of  science  and  technology  development  to 
address  six  long  tenn  challenges  including  global  integration  of  air  and  space  C2. 

c.  Command  and  Control  ( C2 )  Constellation 

The  Concept  of  Operations  (CONOPS)  for  Command  and  Control  (C2) 
Constellation  version  8  (2003)  draws  on  the  objectives  and  desired  effects  of  the  Space 
and  C4ISR  CONOPS  established  in  the  Flight  Plan  to  quickly  deliver  information  to  the 
warfighter.  The  CONOPS  for  C2  Constellation  (2003)  will  provide: 

“...standard  network  services  and  a  shared  Combat  Information 
Environment  to  C2  centers  and  Joint  and  coalition  combat  and  combat 
support  aircraft  to  enable  the  flow  of  decision-quality  information  and 
support  warfighter  collaboration  by  creating  an  intuitive  decision 
environment  through  full  access  to  battlespace  information.  Current 
discrete  air,  ground,  and  space  networks  will  be  adapted  and 
interconnected  to  form  a  seamless  information  dissemination  grid.” 

Battlefield  Management  Command  and  Control  (BMC2)  is  the  heart  of  the 
C2  Constellation  that  will  eliminate  the  current  stovepipe  systems  and  integrate  the 
required  elements  to  achieve  the  desired  Air  Force  capabilities  outlined  in  America’s  Air 
Force  Vision  2020. 

3.  United  States  Navy 

a.  Naval  Power  21 

Naval  Power  2 1  (2002),  signed  by  both  the  Chief  of  Naval  Operations 
(CNO)  and  the  Commandant  of  the  Marine  Corps  (CMC),  presents  a  vision  based  on 
three  pillars:  we  assure  access,  we  fight  and  win,  and  we  are  continually  transforming  to 
improve.  This  document  provides  the  foundation  for  the  Navy’s  Sea  Power  21  and 
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Marine  Corps’  Strategy  21  visions  and  concepts  for  achieving  their  required  service 
capabilities  and  their  required  capabilities  as  part  of  the  future  joint  force. 

b.  Sea  Power  21 

Sea  Power  21  (2002)  defines  the  three  interdependent  Navy  Capability 
Pillars  (NCP):  Sea  Basing,  Sea  Strike,  Sea  Shield,  and  their  network-centric  enabler, 
FORCEnet.  These  concepts  create  the  current  and  future  capabilities  that  will  ensure  the 
Navy’s  ability  to  fulfill  its  portion  of  Naval  Power  21.  These  concepts  rely  on 
information  management  (IM)  and  knowledge  management  (KM)  to  compress  and 
increase  the  lethality  of  the  C2  process.  The  required  information  superiority  is  provided 
by  networked  sensors,  platforms,  and  systems,  persistent  ISR,  and  10. 

c.  Naval  Transformation  Roadmap  2003 

The  Naval  Transformation  Roadmap  2003  (2003),  signed  by  both  the 
CNO  and  CMC,  states  that  every  aspect  of  naval  transformation  is  driven  by  joint 
principles  to  develop  the  NCPs  required  by  the  future  joint  force.  This  document  maps 
the  naval  capability  pillars  against  the  JOpsC,  illustrating  their  applicability.  The 
roadmap  explains  how  current  and  future  Navy  and  Marine  Corps  capabilities  must 
integrate  to  provide  robust,  joint  C2  to  land,  airborne,  sub-surface,  surface,  and  space 
forces  operating  globally. 

d.  FORCEnet:  A  Functional  Concept  for  the  21st  Century 

FORCEnet:  A  Functional  Concept  for  the  21st  Century  (2005),  signed  by 

the  CNO  and  CMC,  defines  FORCEnet  as  “the  operational  construct  and  architectural 
framework  for  naval  warfare  in  the  Information  Age,  integrating  warriors,  sensors, 
command  and  control,  platforms,  and  weapons  into  a  networked,  distributed  combat 
force.”  FORCEnet  provides  the  network-centric  capabilities  enabling  the  NCP  concepts. 
FORCEnet  allows  the  Navy-Marine  Corps  Team  to  generate  the  capabilities  called  for  in 
Naval  Power  21  and  the  JOpsC,  and  readies  naval  forces  for  their  role  in  the  future  joint 
force. 

4.  United  States  Marine  Corps 

a.  Strategy  21 

Strategy  2 1  (2000)  provides  the  broad  visions,  goals,  and  aims  to  develop 
future  USMC  combat  capabilities  and  contributions  to  Naval  Power  21.  Expeditionary 
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Maneuver  Warfare  (EMW)  is  the  centerpiece  of  the  Marine  Corps  vision.  Strategy  21 
(2000)  states,  “Marine  Corps  Strategy  21  guides  a  Marine  Corps  capable  of 
accomplishing  its  specified  and  implied  tasks  derived  from  the  guidance  in  the  National 
Security  Strategy,  the  National  Military  Strategy,  and  other  strategic  documents.” 
Originally  developed  to  meet  the  Joint  Vision  2020  (JV2020)  guidance  on  the  evolution 
of  the  anned  forces,  Strategy  21  speaks  in  terms  of  capabilities  and  remains  relevant  in 
creating  Marine  Corps  capabilities  to  support  the  JOpsC  as  part  of  the  future  joint  force 
(Capstone  Concepts  2005). 

b.  Marine  Capstone  Concepts 

U.S.  Marine  Corps  Concepts  and  Programs  2005  (2005)  sets  forth  EMW 
as  the  capstone  concept  guiding  how  the  USMC  will  organize,  deploy,  employ,  and 
sustain  current  and  future  forces.  Incorporated  into  EMW  are  the  concepts  Operational 
Maneuver  from  the  Sea  (OMFTS),  Ship  to  Objective  Maneuver  (STOM),  Sustained 
Operations  Ashore  (SOA),  and  Other  Expeditionary  Operations  (OEO).  Additional 
concepts  are  Distributed  Operations  (DO)  and  Information  Operations.  These  concepts 
drive  the  need  for  a  robust,  integrated,  and  networked  C2  capability.  They  require 
sustained,  over  the  horizon  operation  by  units  of  various  sizes  throughout  the  battlespace 
and  may  in  fact  shape  the  battlespace,  as  demonstrated  by  the  GWOT. 

c.  Marine  Air  Ground  Task  Force  Command  and  Control 

The  Marine  Air  Ground  Task  Force  Command  and  Control  (MAGTF  C2) 
program  exists  primarily  as  a  collection  of  briefs  outlining  the  concept.  The  presentation 
MAGTF  C2  Strategy  (2005)  describes  MAGTF  C2  as:  ”...  end  to  end,  fully  integrated, 
cross  functional  set  of  MAGTF  C2  capabilities  that  include  forward  deployed  as  well  as 
reach  back.”  Essentially,  MAGTF  C2  envisions  a  system  of  systems  to  achieve 
integration  and  interoperability.  Dukes  (2005),  in  his  MAGTF  C2  Brief  to  the  ISR 
Operational  Advisory  Group  (OAG),  states  C2  must  be  joint  and  mapped  the  MAGTF  C2 
layers  to  the  FORCEnet  capabilities. 

C.  MILITARY  CHAT  RESEARCH 
1.  Center  for  Naval  Analyses 

The  Center  for  Naval  Analyses  (CNA)  researched  chat  performance  in  the  fleet 
during  OEF,  OIF,  and  various  experiments.  This  research  was  conducted  for  the  Office 
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of  the  Chief  of  Naval  Operations  (OPNAV)  N61  and  Commander  of  Naval  Network 
Warfare  Command  (NETWARCOM).  The  findings  are  reported  in  the  following  four 
documents.  While  the  researcher  reviewed  classified  CNA  reports,  only  unclassified 
CNA  work  is  discussed  here. 

a.  Proposed  NETWARCOM  Guidance:  The  Effective  Use  of  Chat 
Banerjee  and  Bentrup  (2002)  document  how  the  introduction  of  chat 

outpaced  the  fleet’s  understanding  of  how  best  to  use  and  manage  it.  The  authors 
develop  an  analytical  framework  for  a  Navy  IM  plan  to  aid  NETWARCOM  in  providing 
clear  guidance  to  the  fleet  regarding  chat  use  (Banerjee  and  Bentrup  2002). 

b.  Fleet  Chat  Requirements 

In  this  white  paper  Banerjee  and  Bentrup  (2003)  wrote  that  an  at-sea 
environment  places  unique  requirements  on  collaborative  tools,  outlined  the  fleet  chat 
requirements,  and  compared  a  number  of  different  tools  against  those  requirements. 
They  reported  that  while  DCTS  met  the  requirements  of  shore -based  users,  it  fell  short  of 
meeting  the  at-sea  requirements  they  outlined. 

d.  Distributed  Internet  Relay  Chat  Architecture 

Bentrup,  Banerjee,  and  Baldwin  (2005)  discuss  distributed  IRC 
architectures,  one  of  the  recommendations  from  in  the  CNA  report  Fleet  Chat 
Requirements.  The  distributed  IRC  architecture  was  compared  to  the  Navy’s  traditional 
hub-and-spoke  architecture.  The  findings  are  summarized  in  Table  6. 


Table  6.  Summary  of  Findings  From  Distributed  Relay  Chat  Architecture  (After:  Bentrup, 
_ Banerjee,  and  Baldwin  2005) _ 

1.  A  distributed  chat  architecture  is  superior  to  the  current  hub-and-spoke  architecture 

2.  Greater  savings  can  be  achieved  by  compressing  the  server-to-server  links 

3.  A  distributed  chat  architecture  is  compatible  with  the  current  hub-and-spoke  architecture. 

4.  The  fleet  needs  to  use  a  single  version  of  IRC  server  software. 

5.  The  fleet  needs  to  recognize  the  value  of  open  source  products. 


c.  Trident  Warrior  04:  Distributed  Internet  Relay  Chat  Architecture 
for  Afloat  Networks 

Bentrup,  Banerjee,  and  Baldwin  (2005a)  analyze  the  distributed  IRC 
architecture  used  during  the  Navy’s  TW04.  Areas  studied  included:  chat  reliability, 
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server-to-server  connectivity  and  reconnect,  bandwidth  efficiency  and  costs,  chat 
availability,  and  affect  on  SA.  Table  7  summarizes  the  operational  results  from  the 
experiment. 


Table  7.  TRIDENT  WARRIOR  04  Distributed  Chat  Architecture  Operational  Results 
_ Summary _ 

1.  Shipboard  server  allowed  users  aboard  USS  TARAWA  to  chat  intra-ship  during 
communications  outages 

2.  Situational  Awareness  improved:  chat  history,  reduced  down  time,  faster  reconnects,  and 
improved  situational  awareness  on  reconnect 

3.  Chat  uptime  (availability)  improved  by  27%  and  average  duration  connection  improved  by  a 
factor  of  5 


2.  Pacific  Science  &  Engineering  Group 

The  Pacific  Science  &  Engineering  Group  (PACSCI)  research  focuses  on  the  HSI 
aspects  of  Navy  chat  use  and  its  evolution. 

a.  Survey  of  Chat  Usage  in  the  Fleet:  Results 
Moore  and  Heacox  (2005)  documented  the  evolution  of  chat  use  during 
OEF  and  OIF.  Surveys  from  183  OIF  chat  users  captured  chat  usage  patterns  and  some 
perceived  warfighter  requirements.  The  survey  was  hosted  online  using  one  of 
Commander,  Carrier  Group  One’s  (CCG-1)  servers.  The  survey  results  are  reported  by 
the  categories  taken  from  the  sample  demographics. 

Moore  and  Heacox  (2005)  discovered  that  79  percent  of  respondents 
participated  in  one  to  four  chat  rooms  and  that  23  percent  participated  in  5  or  more. 
While  participating  in  these  chat  rooms,  65  percent  of  respondents  monitored  one  to  four 
additional  chat  rooms  and  23  percent  monitored  an  additional  five  or  more  (Moore  and 
Heacox  2005).  Figure  4  shows  what  four  of  the  respondent  groups  used  chat  for. 
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Figure  4.  Purpose  for  chat  use  (as  percentage)  by  respondent  group  (After:  Heacox  and 

Moore  2005) 


b.  Usability  of  Chat  in  the  Maritime  Coalition  Environment: 
Empirical  Findings  from  a  Limited  Objective  Experiment  for 
Trident  Warrior  2005 

Catanzaro,  Gwynne,  and  Mitchell  (2005)  report  their  findings  from  a  LOE 
where  novice  and  experienced  chat  users  perfonned  a  series  of  24  tasks.  Task 
performance  was  evaluated  for  live  different  chat  tools,  summarized  within  this  report, 
with  an  individual  report  for  each  chat  tool  (listed  in  the  bibliography).  Catanzaro, 
Gwynne,  and  Mitchell  (2005)  concluded  that  chat  HSI  features  should  be  implemented  in 
terms  of  the  operational  requirements  for  chat  in  a  maritime  coalition  environment,  that 
there  are  numerous  interface  design  features  that  affect  the  chat  tools’  ability  to  meet 
these  requirements,  and  that  a  prioritized  list  of  chat  features  can  be  used  to  develop 
interface  design  guidelines  for  naval  chat. 

3.  Massachusetts  Institute  of  Technology 

In  Cummings  (2004),  Need  for  Command  and  Control  Instant  Message  Adaptive 
Interfaces:  Lessons  Learned  from  Tactical  Tomahawk  FIuman-in-the-Loop  Simulations, 
researchers  uncovered  some  interesting  data  concerning  chat  use.  Results  indicated  that 
some  operators  focused  on  the  chat  tool  rather  than  their  primary  task  of  missile  control, 
which  lead  to  degradation  of  performance  and  SA. 
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This  is  some  of  the  first  research  documenting  some  of  the  issues  arising  from  the 
proliferation  of  chat  use.  The  results  of  the  report  are  not  unexpected  and  are  in  fact  often 
discussed  within  the  military,  but  only  generally  and  anecdotally. 


21 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


22 


III.  METHODOLOGY 


A.  RESEARCH 

The  very  nature  of  chat’s  unofficial  status  made  the  study  of  existing  research 
difficult.  Most  chat-related  documents  consist  of  briefs  and  presentations,  unpublished 
internal  reports,  and  email  discussions.  Significant  and  continued  effort  was  spent 
soliciting,  collecting,  and  consolidating  these  materials  into  the  required  knowledge  base. 
Once  accomplished,  information  gaps  were  identified  with  three  key  gaps  becoming 
immediately  apparent: 

•  most  information  addressed  chat  indirectly  and  at  the  service  level  or 
major  command  level 

•  information  collected  from  “lower  levels”  provided  no  documentation  of 
what  “lower  levels”  actually  referred  to,  nor  was  the  summarized  or  raw 
input  available 

•  no  one  was  in  charge  of  chat,  at  best  a  person  involved  in  collaboration 
had  some  involvement,  more  commonly  it  was  a  civilian  employee  that 
“unofficially”  addressed  chat 

Based  upon  these  key  information  gaps,  this  thesis  focused  its  research  effort  at 
the  tactical  level.  Example  units  are:  Army  Brigade  (Brigade  Combat  Teams)  and  below, 
Marine  Regiment  (Regimental  Combat  Teams)  and  below,  Air  Force  Squadron  and 
below,  Navy  Expeditionary  or  Carrier  Strike  Groups  down  to  the  single  ship.  While 
focused  on  the  tactical,  research  was  also  conducted  to  verify  stated  chat  use  and 
requirements  at  the  operational  and  the  strategic  levels. 

1.  DIRECT  OBSERVATION 

The  researcher’s  personal  experience  as  a  US  Marine  Corps  Command  and 
Control  Systems  Officer  (Military  Occupational  Specialty  0602)  provided  an  applied  chat 
knowledge  base.  This  knowledge  base  includes  the  planning,  installation,  operation,  and 
maintenance  of  various  chat  tools  with  infantry,  artillery,  special  operations  forces,  and 
embarked  amphibious  units.  Experience  gained  using  chat  as  a  watch  officer 
demonstrated  the  difficulties  in  successfully  integrating  chat  with  warfighting  doctrine. 
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The  researcher  also  participated  in  the  Navy’s  annual  Sea  Trial  Experiment, 
TW05.  This  allowed  the  researcher  to  observe  and  participate  in  planning,  chat  tool 
development,  chat  limited  objective  experiments,  and  document  first  hand  joint  and 
coalition  chat  use  at  sea  during  a  major  joint  and  combined  exercise  scenario  with  a  US 
Navy  Expeditionary  Strike  Group. 

2.  SURVEYS  AND  INTERVIEWS 
a.  Selecting  Participants 

The  survey  and  interview  process  targeted  military  officers  at  the  tactical 
level,  pay  grades  0-3  and  0-4.  This  group  represents  typical  unit  commanders,  staff 
officers,  and  watch  officers  across  the  services.  Appendix  B  provides  the  full  survey 
demographics  of  respondents.  Table  8  summarizes  the  pay  grades  of  respondents  by 
service  from  Appendix  B. 


Table  8.  Pay  grades  of  respondents  by  service 


Organization 

05 

04 

03 

02 

Total 

US  Marine  Corps 

0 

10 

16 

2 

28 

US  Air  Force 

0 

6 

8 

1 

15 

US  Navy 

1 

2 

4 

0 

7 

US  Army 

0 

2 

1 

0 

3 

Canadian  Forces 

0 

0 

1 

0 

1 

Royal  New 
Zealand  Navy 

0 

1 

1 

0 

2 

Royal  Australian 

0 

1 

0 

0 

1 

Navy 

Total 

1 

22 

31 

3 

58 
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Table  9  summarizes  the  operational  tours  of  respondents  by  operation 
From  Appendix  B. 


Table  9.  Number  of  tours  of  survey  respondents  by  operation 


Operation 

Tours 

ENDURING  FREEDOM 

23 

ENDURING  FREEDOM-PHILIPPINES 

1 

IRAQI  FREEDOM  - 1 

26 

IRAQI  FREEDOM  -  II 

9 

SUBSEQUENT  IRAQI  FREEDOM  ROTATION 

2 

SOUTHERN  WATCH 

7 

UPHOLD  DEMOCRACY 

1 

ALLIED  FORCE 

1 

PROVIDE  COMFORT 

1 

SECURE  TOMRROW 

1 

JTF-Katrina 

2 

ALTAIR  (CANADIAN  OEF  PARALLEL) 

1 

UNISON  (CANADIAN  KATRINA  RELIEF) 

1 

b.  Administering  Surveys  and  Interviews 

The  surveys  and  interviews  were  administered  with  the  same  device  from 
Appendix  C  to  ensure  continuity  of  results  between  the  two  forms  of  data  collection. 
Rather  than  use  a  web-based  survey,  the  survey  was  emailed  to  participants  to  introduce  a 
response  bias,  limiting  respondents  to  those  that  had  actually  used  chat  and  were  willing 
to  take  the  time  to  complete  the  survey,  save  it,  and  email  it  back.  This  resulted  in 
extremely  high  quality  responses  that  were  easily  incorporated  into  the  research.  Despite 
this  built-in  bias,  there  were  still  numerous  responses  that  were  simply  not  useful  or  the 
respondent  never  used  chat. 

3.  AAR/LL 

UNCLASSIFIED,  CONFIDENTIAL,  and  SECRET  after  action  reports  and 
lessons  learned  were  reviewed.  In  an  effort  to  reach  the  broadest  possible  domestic  and 
foreign  audience,  only  the  UNCLASSIFIED  are  reported  on  specifically  in  this  thesis. 
An  in-depth  review  of  the  classified  reports  and  lessons  learned  found  no  substantive 
differences  from  the  UNCLASSIFIED  ones;  they  simply  contained  non-releasable 
specifics  and  details.  Table  10  provides  the  number  of  action  reports  and  lessons  learned 
reviewed  by  organization. 
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Table  10.  Number  of  After  Action  Reports/Lessons  Learned  by  organization 

Organization _ Number _ 


US  Army 

18 

US  Navy 

570 

US  Air  Force 

70 

US  Marine  Corps 

107 

US  Coast  Guard 

220 

Combatant 

Command 

17 

B.  DISCUSSION 

Much  of  this  thesis  research  was  qualitative.  Surveys,  supplemented  with 
extensive  personal  communication  were  used  to  uncover  user  expectations  and  common 
requirements  in  collaboration  tools. 

C.  ANALYSIS 

The  unstructured  nature  of  the  text-based  chat  requirements  and  lack  of  clear 
problem  definition  required  an  artful,  systems  architecting  approach.  The  two 
architecting  methodologies  primarily  used  were  the  Participative  (stakeholder-based)  and 
the  Heuristic  (lessons  learned)  and  are  considered  the  “art”  part  of  systems  engineering 
(Maier  and  Rechtin  2002).  The  ad  hoc  nature  that  led  us  to  this  point  in  chat  use  dictates 
that  a  participative,  stakeholder  approach  is  critical.  The  fact  that  the  chat  “problem” 
(however  undefined)  is  only  now  being  addressed,  after  years  of  actual  operational  use, 
means  there  exists  some  historical  record  of  use  that  we  may  apply  heuristics  to  draw 
insight.  However,  scientific  methodologies  like  the  normative  (solution-based)  or  the 
rational  (methods-based)  were  also  used. 

The  participative  methodology  recognizes  numerous,  conflicted  stakeholders  exist 
and  makes  its  objective  consensus  (Maier  and  Rechtin  2002).  This  plays  to  chat’s  wide 
use,  its  varied  users,  and  the  proliferation  of  tools.  The  heuristic  methodology  is  a 
“common  sense”  approach  based  on  collective  wisdom  simply  and  concisely  stated 
(Maier  and  Rechtin  2002). 

Systems  engineers/architects  and  project  managers  may  only  work  on  a  few  major 
projects  in  their  lifetime,  resulting  in  a  focused  experience  within  a  certain  field. 
Heuristics  serve  as  an  abstraction  for  experience,  allowing  people  to  draw  on  past 
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experience  from  other  fields  and  functions  to  address  problems  within  their  own  (Maier 
and  Rechtin  2002). 

This  thesis  focused  on  warfighter  involvement  and  chat  lessons  learned  to  clearly 
state  the  problem,  document  experience,  and  develop  a  framework  that  allows  future 
researchers  to  scientifically  approach  text-based  chat.  In  parallel,  this  thesis  also 
participated  in  major  scientific  experimentation  regarding  text-based  chat  to  aid  in  the 
research  and  to  act  as  a  check  and  balance. 

D.  EXPERIMENTATION 

1.  TRIDENT  WARRIOR  Objectives 

“Define  Navy  FORCEnet  DOTMLPF  requirements  for  a  maritime  chat  tool”  was 
a  stated  objective  of  TW05,  NETWARCOM’s  annual  FORCEnet  Sea  Trial  exercise 
(TW05  Analysis  Report  2006).  Table  1 1  lists  the  IM  chat  initiative  objectives. 


Table  11.  1 

rRIDENT  WARRIOR  Infonnation  Management  chat-related  objectives 

Objective  2 

Universal  Chat  Client  (UCC)  -  Assess  the  capability  of  UCC  to  fill  the  documented  gaps  that 
currently  exist  in  current  maritime  chat  protocols  used  throughout  the  US  Navy. 

Objective  3 

Uber  Chat  -  Does  Uber  Chat  provide  functionality  that  fills  identified  gaps  in  current  maritime 
chat  protocols? 

Objective  4 

Extensible  Messaging  and  Presence  Protocol  (XMPP)  -  Does  XMPP  provide  functionality 
that  fills  identified  gaps  in  current  maritime  chat  tools? 

Objective  5 

Multi-Level  Chat  (ML  Chat)  -  Does  ML  Chat’s  unique  functionality  of  chatting  across  two  or 
more  domains  provide  the  functionality  necessary  for  Navy  Maritime  Chat? 

Objective  6 

Persistent  War  Room  (PWR)  -  Will  PWR  and  Chat  Logging  operate  over  lower  bandwidth 
subnets  and  provide  the  operator  ready  access  to  chat  functions  and  supporting  information  as 
well  as  archived  chat  logs? 

Objective  8 

Distributed  Chat  Architecture  (DCA)  -  Compare  the  proposed  DCA  (hub  and  leaf)  to  the 
current  (hub  &  spoke)  IRC  communications  architecture.  Provide  a  technical  solution  to 
operator  concerns  including  loss  of  situational  awareness,  reconnection  to  servers  after  a 
communications  outage,  intra-ship  text  chat  communications  when  off-ship  communications  are 
down. 

Source :  TW05  Analysis  Report 


The  experiment  was  conducted  at  sea  while  executing  a  week-long  tactical 
scenario  that  included  US  naval  and  coalition  ships,  embarked  24th  Marine  Expeditionary 
Unit  Special  Operations  Capable  (MEU  (SOC))  staff,  shore-based  units,  and  numerous 
manned  and  unmanned  aircraft.  Different  data  network  conditions  were  implemented  to 
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evaluate  the  objectives  under  communications  conditions  from  ideal  to  severely 
degraded. 

The  thesis  researcher  worked  with  NETWARCOM’s  TW05  IM  Lead  during  all 
stages  from  planning  through  execution.  This  provided  the  opportunity  to  participate 
with  one  of  the  services  on  defining  their  chat  requirements  as  part  of  a  major  joint  and 
coalition  experiment  with  the  USS  IWO  JIMA  ESG,  the  24th  MEU  (SOC),  and  the 
AUSCANNZUKUS  coalition. 

In  preparation  for  TW05,  the  researcher  participated  in  a  risk  reduction  LOE 
conducted  at  SSC-SD.  The  LOE  had  two  parts.  In  first  part  researchers  from  the  CNA 
tested  the  distributed  chat  architectures  planned  for  use  during  TW05  and  simulated  the 
various  network  conditions  planned. 

The  second  part  consisted  of  HSI  studies  conducted  by  PACSCI  on  the  chat  tools 
that  were  going  to  be  used  during  TW05.  This  was  crucial  to  the  spiral  development 
approach  used  for  some  of  the  chat  tools.  They  were  developed  with  previously  collected 
and  developed  chat  tool  requirements.  The  LOE  allowed  the  PACSCI  scientists  to 
observe  users  operating  the  chat  tools  and  develop  a  refined  requirements  list.  These 
refined  requirements  allowed  the  NETWARCOM  IM  Lead  and  the  chat  tool  developers 
to  re-design  the  chat  tools  in  preparation  for  TW05. 

2.  TRIDENT  WARRIOR  Background 

TRIDENT  WARRIOR  operates  under  the  supporting  concept  of  Sea  Trial  that 
supports  the  Naval  Capability  Pillars.  Sea  Trial:  Commander  U.S.  Fleet  Forces 
Command  Instruction  (COMFLTFORCOMINST)  3900.1  (2003)  establishes 

responsibilities  and  prescribes  general  procedures  for  Sea  Trial  implementation  and  states 
the  Marine  Corps,  as  part  of  the  naval  force,  is  an  equal  partner  at  all  levels  of  Sea  Trial, 
with  the  Commanding  General  (CG),  Marine  Corps  Combat  Development  Commanded 
(MCCDC)  the  Marine  Corps  Sea  Trial  coordinator. 

The  Sea  Trial  Executive  Steering  Group  (STESG)  members  defined  by  Sea  Trial 
include  major  Navy  and  Marine  Corps  commands  and  agencies.  The  instruction 
designates  Commander  Naval  Network  Warfare  Command  (COMNAVNETWARCOM) 
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as  the  Sea  Trial  Operational  Agent  for  FORCEnet.  Naval  Postgraduate  School  is  tasked 
with  concept  development  and  research  in  support  of  the  NCPs  and  FORCEnet. 
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IV.  FINDINGS 


This  chapter  has  four  sections:  chat  use  cases,  an  analysis  of  why  chat  is  used,  an 
examination  of  chat’s  risks,  and  a  requirements  framework. 

A.  USE  CASES 

The  warfighter  has  expanded  the  role  of  chat  across  the  full  spectrum  of  military 
operations.  Commanders  and  innovative  operators  at  all  levels  and  units  have  grown 
their  own  chat  solutions  to  complex  C2  problems  despite  the  many  systems  fielded  to 
solve  the  same.  Chat  is  used  by  the  warfighter  to  put  steel  on  target,  or  conversely,  to 
build  schools  and  repair  mosques.  These  operational  examples  are  intentionally  broad  to 
provide  a  brief  yet  substantive  illustration  of  the  far-reaching  use  of  chat  for  military  C2. 
Table  12  lists  these  use  cases  by  functional  area. 


Table  12.  Use  cases  by  functional  area 


J-3  Operations 

J-2  Intelligence 

Multinational  Operations 

Counterintelligence 

Disaster  Relief  Operations/Civil 
Military  Operations 

National  Intelligence  Support  to  Joint 
Operations 

Antiterrorism/Homeland  Defense 

Special  Operations 

UAV  Operations 

T  argeting 

Close  Air  Support 

Combat  Recovery 

Medical  Evacuation 

Meteorological  and  Oceanographic 
Support  to  Joint  Operations 

1.  J-3  Operations 

a.  Multinational  Operations 

Her  Majesty’s  Canadian  Ship  (HMCS)  TORONTO  (FFH-333) 
participated  in  OPERATION  ALTAIR  (Canadian  OEF  parallel)  in  2004.  She  deployed 
as  a  fully  integrated  escort  of  the  USS  GEORGE  WASHINGTON’S  (CVN-73)  Carrier 
Strike  Group  (CSG)  to  the  Arabian  Gulf. 
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The  CSG  exercised  C2  with  chat  over  SIPRNET  (Secure  Internet  Protocol 
Routed  Network),  which  HMCS  TORONTO  (the  CSG’s  only  foreign  ship)  could  not 
access.  Canadian  Forces  task  by  voice;  however,  the  CSG  used  the  coalition  wide  area 
network  (COWAN)  chat  for  tasking  HMCS  TORONTO,  with  voice  circuits  as  backup. 
United  Kingdom  and  New  Zealand  vessels  in  the  area  of  operations  (AO)  were  also  on 
COWAN  chat. 

TORONTO  stood  picket  duty  in  sector  screen  for  the  CSG,  tasked  and 
coordinated  over  COWAN  chat.  Tasking  orders  for  urgent  maritime  interdiction 
operations  (MIO)  were  sent  to  HMCS  TORONTO  over  the  COWAN  chat  and  she 
boarded  123  ships  for  the  CSG. 

The  Combat  Officer,  HMCS  TORONTO  summed  up  chat  issues  from  the 
Canadian  point  of  view.  The  U.S.  Navy  did  not  rely  on  a  single  chat  tool  for  C2.  With 
HMCS  TORONTO  as  the  only  non-U. S.  warship  it  was  easy  for  the  CSG  to  overlook  the 
need  to  use  COWAN  chat.  Even  with  a  liaison  officer  (LNO)  aboard  the  George 
Washington  and  six  months  together,  the  U.S.  never  made  the  leap  to  using  COWAN  and 
continued  using  primarily  SIPRNET  chat.  The  recommendation  was  that  coalition  forces 
should  use  coalition  networks. 

b.  Disaster  Relief  Operations/Civil  Military  Operations 

Amphibious  Squadron  Four  (PHIBRON4),  embarked  aboard  the  USS 
IWO  JIMA  (LHD-7),  used  chat  for  C2  during  humanitarian  operations  with  Joint  Task 
Force-Katrina  (JTF-Katrina).  Chat  was  used  extensively  to  plan,  task,  and  coordinate 
pre-deployment  and  underway.  Upon  arrival  in  New  Orleans,  the  movement  of 
amphibious  craft  for  transporting  personnel,  equipment,  and  supplies  ashore  was 
coordinated  and  tracked  through  chat.  Situation  Reports  (SITREPs)  from  the  ships  and 
detachments  ashore  were  sent  to  PHIBRON4  with  chat  and  then  sent  from  PHIBRON4  to 
Amphibious  Group  2  (PHIBGRU2)  by  the  same  means.  After  Hurricane  Rita,  the  USS 
TORTUGA  (LSD-46),  in  Cameron,  Louisiana,  passed  infonnation  on  its  amphibious 
craft  operations  and  SITREPs  over  chat  to  PHIBRON4,  still  embarked  on  the  USS  IWO 
JIMA  in  New  Orleans. 
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Canada  executed  Operation  UNISON  in  response  to  Hurricane  Katrina, 
sending  its  East  Coast  Task  Group,  including  HMCS  TORONTO  (FFH-333),  to  Biloxi, 
Mississippi  during  September  and  October  of  2005.  Operations  were  reported  to  the  USS 
Saipan  using  Maritime  Command  Operational  Information  Network  (MCOIN)  chat 
(MCOIN  facilitates  Canadian  maritime  C2  with  U.S.  Navy).  The  Canadian  Task  Group 
requested  and  coordinated  landing  support  for  its  engineers,  wood,  generators,  and  other 
supplies  over  MCOIN  chat. 

United  States  Marine  Forces  Atlantic  (USMARFORUANT)  recognized  a 
gap  in  its  C2  capability  during  JTF-Katrina  operations.  The  USMARFORLANT  lessons 
learned  from  JTF-Katrina  included  one  entitled  “Real  Time  Infonnation  Dissemination.” 
Watch  Officers  had  difficulty  disseminating  timely  information  with  email.  Citing 
successful  chat  usage  in  OIF  for  the  conduct  of  fire  [fire  support]  and  unmanned  aerial 
vehicle  (UAV)  operations,  it  was  recommended  that  USMARFORLANT  establish  chat 
rooms  to  support  real  time  information  dissemination  (Gray  2005). 

The  Area  of  Responsibility  (AOR)  for  the  U.S.  Southern  Command 
(USSOUTHCOM)  is  a  huge  geographic  area  where  disaster  relief  efforts  are  not 
uncommon  and  civil  military  operations  (CMOs)  are  the  norm.  Headquarters 
USSOUTHCOM  uses  the  chat  capabilities  of  DOTS  to  coordinate  and  support  CMOs  in 
its  AOR.  Chat  was  used  to  coordinate  disaster  relief  efforts  for  the  flooding  in  Guatemala 
caused  by  Hurricane  Stan  in  2005. 

c.  Antiterrorism/Homeland  Defense 

An  antiterrorism  vignette  from  Commander  Coast  Guard  District  14 
message  162008Z  MAY  03,  After  Action  Report:  Terrorism  Threat  on  Board  Cruise  Ship 
Legend  of  the  Seas  (LOS),  22-24  April  03: 

On  22  April  2003  Royal  Caribbean  Cruise  lines  cruise  ship  Legend  of  the 
Sea  (LOS)  was  en  route  from  Ensenada,  Mexico  to  Hilo,  Hawaii  for  a 
scheduled  port  call  with  1668  passengers  and  701  crewmembers.  A 
cleaner  found  a  written  note  in  a  restroom  threatening  the  lives  of 
American  passengers  onboard.  LOS  reported  the  note  to  Royal  Caribbean 
Cruise  Lines  who  informed  the  National  Response  Center  (NRC)  and  the 
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Federal  Bureau  of  Investigation  (FBI).  Captain  of  the  Port,  Honolulu, 
ordered  LOS  to  not  enter  port  and  divert  to  anchorage  offshore.  A  123 
member  multi-agency  boarding  was  conducted  to  secure  and  clear  LOS 
(D14  2003). 

Coast  Guard  District  14  (D14)  assumed  Lead  Federal  Agency  (LFA)  for 
the  boarding  and  operated  in  two  SIPRNET  chat  rooms  that  included  USCG  Pacific  Area, 
US  Pacific  Command  (USPACOM),  Commander  U.S.  Pacific  Fleet,  and  93rd  Weapons 
of  Mass  Destruction  Civil  Support  Team  (93rd  WMD-SCT). 

A  Marine  Corps  Visit,  Board,  Search  and  Seizure  (VBSS)  vignette  from 
the  2003-2004  deployment  of  the  13th  MEU  (SOC)  in  the  Arabian  Gulf: 

The  Maritime  Special  Purpose  Force  (MSPF)  Commander  is  aboard  the 
shouldering  ship  with  laptop  and  chat  connectivity.  The  Force  Platoon 
Commander  is  on  the  boarded  vessel.  They  were  in  contact  over  voice 
radio,  but  the  MSPF  Commander  was  in  contact  with  the  Landing  Force 
Operations  Center  [LFOC]  aboard  a  US  Navy  amphibious  ship  using  chat. 
Prowords  for  mission  segments,  information  requests,  and  the  unfolding 
mission  were  passed  and  tracked  in  chat.  The  LFOC  passed  additional 
tasking  to  the  MSPF  as  the  mission  progressed.  The  VBSS  resulted  in  the 
seizure  of  hashish  with  an  estimated  value  in  the  millions. 

d.  Special  Operations 

In  2002  and  2003,  during  OEF  in  Afghanistan,  units  from  Third  Special 
Forces  Group  (Airborne)  operated  widely  dispersed  as  part  of  the  Combined  Special 
Operations  Task  Force  (CJSOTF).  Third  Group  was  equipped  with  AN/PSC-5  Satellite 
Radios,  but  assigned  a  single  voice  satellite  communications  (SATCOM)  channel  shared 
by  the  entire  CJSOTF  within  the  theater  and  reserved  for  command,  emergencies,  or  units 
in  contact.  The  SATCOM  radios  were  data  capable  with  ruggedized  laptops  allowing 
Special  Forces  teams  to  send  free  text  messages.  This  is  significant,  because  despite  not 
having  an  actual  chat  tool,  units  used  the  free  text  messaging  capability  to  provide  an 
improvised  chat  (more  specifically  instant  messaging)  functionality  to  fill  the  C2  gap. 
Army  Special  Forces  firebases  always  had  SATCOM  connectivity  with  the  text 
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messaging  capability  running  and  most  business  within  the  lirebascs  was  conducted  by 
text  conversations.  While  on  the  move  during  operations,  teams  were  contacted  over 
voice  SATCOM  and  told  to  come  up  on  the  laptops  for  text  messaging. 


One  Special  Forces  Operational  Detachment  A  (ODA)  Commander 
recounted  how  this  text-based  communications  capability  aided  operations.  His  ODA 
team  was  operating  in  an  area  where  another  unit’s  mission  fell  through.  His  team 
received  a  voice  call  over  SATCOM  to  come  up  on  SATCOM  data.  With  the  text 
messaging  capability  he  received  a  fragmentary  order  (FRAGO),  acknowledged  receipt, 
and  discussed  operational  details.  This  improvised  chat  capability  allowed  the  ODA 
team  to  execute  the  FRAGO  much  more  rapidly  than  if  a  voice  exchange  had  taken  place. 
The  ODA  executed  a  cordon  and  search  of  a  small  village,  resulting  in  two  personnel 
under  control  (PUCs  -  enemy  combatants;  not  prisoners  of  war)  and  capture  of  a 
weapons  cache.  The  SITREP  was  sent  to  higher  headquarters  using  the  improvised  chat 
capability,  which  would  read  it  and  start  asking  questions  back. 

In  another  case,  after  mission  completion,  an  ODA  team  sent  a  SITREP  to 
higher  headquarters  using  the  improvised  chat.  The  CJSOTF  replied  immediately 
concerning  the  PUCs  the  ODA  had  in  custody.  The  ODA  Commander  replied,  telling  the 
CJSOTF  when  and  where  the  Afghan  Militia  Forces  (AMF)  captured  the  PUCs,  passed 
their  descriptions,  what  PUC1  and  PUC2  said  when  debriefed,  and  that  they  had  dual 
identification  that  did  not  check  out.  He  also  reported  that  they  had  weapons  and  were 
seen  leaving  a  large  cache  with  rifle  propelled  grenades  (RPGs),  Soviet  style  mines, 
detonation  cord,  etc.  Information  continued  to  be  passed  and  then  the  CJSOTF  directed 
the  ODA  team  to  maintain  positive  control  of  the  PUCs  and  document  all  information 
about  them.  The  total,  detailed  exchange  required  only  a  couple  of  minutes  with  the 
improvised  chat. 

e.  UA  V  Operations 

Sixth  Marine  Regiment  used  chat  for  global  collaboration  during  Direct 
Support  (DS)  UAV  operations.  Sixth  Marines,  in  Afghanistan  for  OEF,  used  chat  to 
communicate  with  the  Air  Force  UAV  pilot  and  payload  operator  at  Nellis  Air  Force 
Base  (AFB),  Nevada.  During  the  UAV  mission,  the  regiment  requested  specific  actions 
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by  the  pilot  and  the  payload  operator  in  real  time,  while  the  Anny  Collection  Manager  for 
the  CJTF  monitored  the  chat  room  and  tracked  the  mission. 

Second  Battalion,  Fifth  Marines  (2/5)  used  chat  for  UAV  operations  in 
OIF  I  and  OIF  II.  Chat  allowed  2/5  to  direct  the  pilot  and  the  payload  operator  during  the 
mission  and  disseminate  what  the  UAV  was  seeing. 

Marine  Unmanned  Aerial  Vehicle  Squadron  Two  (VMU-2)  used  chat 
extensively  during  OIF  II  and  OIF  III.  Chat  was  used  for  UAV  support  to  targeting, 
strike  execution,  and  close  air  support  (CAS)  for  units  supported  by  VMU-2  UAVs. 

f  Targeting 

Third  Infantry  Division  (3ID)  OIF  targeting  vignette: 

Baghdad... watched  a  BM-21  moved  to  outskirts  of  city  S/SE;  fires  3-5 
rounds,  returns  to  city.  3ID  following  on  UAV  (in  DS  to  DIV)  and  tracks 
launcher  back  into  the  city  where  launcher  links  with  re-supply  vehicle. 

96D  SGT  HOLT,  Paul  is  watching  on  GBS  [Global  Broadcast  System] 
monitor  and  is  in  mIRC  Chat  talking  to  Air  Force  FAC  [Forward  Air 
Controller]  while  the  Targeting  Officer,  1LT  Elizabeth  Snyder  is  talking  to 
CFACC  [Combined  Force  Air  Component  Commander]  in  parallel.  SGT 
Holt  verifies  grid  and  confirms  target.  Air  force  destroys  target.  Total 
time  of  sensing  to  shooter  -  20  minutes... would  have  been  earlier  but  he 
[BM-21]  was  driving  in  residential  area... ACE  did  not  see  the  re-supply 
vehicle  in  the  field  he  drove  into  until  the  BM-2 1  stopped  at  its  hide  site 
(CALL  2003). 

The  US  Air  Force’s  421st  Fighter  Squadron  used  SIPRNET-based  chat  for 
time  sensitive  targeting.  This  allowed  collaboration  with  the  Combined  Air  Operations 
Center  (CAOC)  at  A1  Udeid  Airbase  for  questions  on  targets,  the  ATO,  or  strike -related 
questions  and  coordination  with  parallel  agencies.  Dynamic  targeting  and  strikes  were 
also  facilitated  by  chat.  For  example,  a  ground  unit  calls  in  a  troops  in  contact  (TIC) 
report,  the  information  flows  to  squadron  operations,  which  can  then  re-task  aircraft  to 
collect  targeting  intelligence  or  to  execute  CAS.  This  applied  to  situations  beyond  troops 
in  contact  like  pipeline  attacks  or  suspicious  activity  where  jets  from  the  421st  would  be 
re-tasked  to  a  specific  target  for  surveillance.  The  squadron  monitored  the  mission  and 
watched  the  CAOC  direct  events.  Monitoring  the  mission  in  chat  aided  in  debrief 
preparation  and  expedited  the  debrief/mission  report  process  once  the  pilots  returned. 
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g.  Close  Air  Support 

During  OIF  the  4th  Air  Support  Operations  Group  (4th  ASOG)  attached  to 
the  US  Army  V  Corps  used  chat  continuously  for  CAS  execution  among  US  Army  V 
Corps,  Coalition  Land  Forces  Component  Command  (CFLCC),  Combined  Force  Air 
Component  Commander  (CFACC),  and  Marine  Expeditionary  Forces  (MEF).  They 
provided  C2  for  all  V  Corps  CAS  missions  and  considered  chat  absolutely  critical  to 
mission  accomplishment  because  it  was  the  most  expedient  method  of  communication 
and  allowed  real-time  collaboration. 

Chat  was  used  by  4th  ASOG  to  task  UAVs  (Predator,  Hunter,  Shadow, 
Global  Hawk)  and  other  assets  to  collect  and  disseminate  intelligence  to  Tactical  Air 
Control  Parties  (TACP),  CAS  aircraft,  V  Corps  ACE  (Analysis  and  Control  Element), 
and  any  other  units  requiring  the  information  for  CAS  execution.  Chat  was  further  used 
for  de-confliction  of  CAS,  joint  fire  support,  and  of  CAS  and  UAV  airspace,  real-time, 
within  V  Corps,  MEF,  CFACC,  UAV  units,  and  Air  Force  Distributed  Ground  Stations 
(AF  DGS)  -  the  people  exploiting  UAV  imagery. 

The  22d  MEU  (SOC)  in  Afghanistan  for  OEF  coordinated  details  of 
emergency  CAS  tasking  over  chat,  mainly  for  the  requesting,  allocating,  and  tasking 
stages.  The  senior  watch  officer  would  post  TIC  reports  in  the  main  chat  room  and  CAS 
details  would  be  worked  out  in  the  same  room  or  in  private  chat  with  liaison  officers  at 
CJTF-76  ACCE.  Changes  to  CAS  were  discussed  in  chat  before  and  during  the  mission. 
Changes  would  be  sent  to  coordinating  agencies  in  chat  and  from  there  radioed  to 
airborne  aircraft.  The  Marine  Direct  Air  Support  Center  (DASC)  used  chat  to  update 
what  aircraft  would  execute  CAS  and  their  status  (i.e.  tanking,  time  remaining  on 
station). 

h.  Combat  Recovery 

The  421st  Fighter  Squadron  used  chat  extensively  in  every  combat  search 
and  rescue  (CSAR)  mission  during  OIF.  Chat  was  the  primary  tool  used  with  UHF/VHF 
voice  circuits  for  airspace  de-confliction  and  for  supporting  arms  and  close  air  support 
(CAS)  coordination  during  combat  recovery  missions.  The  24th  MEU  (SOC)  used  chat 
during  OIF  I  and  OIF  II  to  request  aircraft  for  combat  recovery  missions  and  to  pass 
information. 
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Helicopter  Anti-Submarine  Squadron  3  (HS-3  “TRIDENTS”)  embarked 
aboard  the  USS  ENTERPRISE  (CVN-65)  for  OEF,  used  chat  for  joint  CSAR.  The 
TRIDENTS  supported  joint  maritime  CSAR  and  CSAR  for  western  Pakistan  and 
southern  Afghanistan. 

Chat  was  also  used  for  search  and  rescue  missions  (SAR)  in  the  United 
States.  Again,  HS-3  used  chat,  this  time  to  coordinate  a  joint  Navy  and  Coast  Guard 
maritime  rescue  off  of  North  Carolina. 

i.  Medical  Evacuation 

Chat  played  a  significant  role  in  the  medical  evacuation  (MEDEVAC) 
process  around  the  world  and  across  the  spectrum  of  military  operations.  Chat  was  used 
in  Afghanistan  during  OEF  by  CJTF-180  to  coordinate  MEDEVACS  of  combat  and  non¬ 
combat  casualties.  The  CJTF  also  used  chat  to  clear  fires  in  the  MEDEVAC  airspace. 
The  22nd  MEU  (SOC)  also  used  chat  for  MEDEVACS  as  part  of  CJTF-180  and  later 
CJTF-76  in  Afghanistan  during  OEF.  Units  posted  MEDEVAC  9-lines  (standardized 
request  format)  to  the  main  chat  room  and  the  MEU  would  either  task  their  organic  air 
assets  with  the  MEDEVAC  over  chat  or  use  chat  to  request  support  from  higher 
headquarters.  When  Third  Battalion,  Sixth  Marines  (3/6)  received  a  unit  in  contact 
report  they  immediately  monitored  the  MEDEVAC  preparations  in  the  aviation  brigade’s 
chat  room  and  passed  MEDEVAC  information  to  the  CJTF  in  chat. 

During  two  deployments  to  Iraq,  Helicopter  Marine  Heavy  Squadron-465 
(HMH-465)  received  tasking  from  higher  to  execute  MEDEVACs.  The  9-line 
(MEDEVAC)  information  was  passed  to  the  squadron  over  chat  and  then  handed  to  the 
MEDEVAC  pilot  just  prior  to  launch.  This  information  included  grid  coordinates,  radio 
frequencies,  what  to  expect  at  the  landing  zone  (LZ),  etc. 

Chat  was  also  used  to  coordinate  MEDEVACs  during  Disaster  Relief 
Operations.  The  USS  IWO  JIMA  used  chat  to  coordinate  MEDEVACs  as  part  of  JTF- 
Katrina 

j.  Meteorological  and  Oceanographic  Support  to  Joint  Operations 

Meteorological  and  oceanographic  (METOC)  forecasting  support  affects 

joint  and  combined  operations  across  the  full  military  spectrum.  Chat  has  proven  a  vital 
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tool  for  coordinating  weather  forecasts  for  various  theaters.  Southern  Command  METOC 
(J332)  personnel  used  chat  during  Operation  SECURE  TOMORROW  to  coordinate 
weather  support  for  Royal  Canadian  Air  Force  helicopters  flying  in-and-around  Port-au- 
Prince,  Haiti. 

The  28th  Operational  Weather  Squadron  (OWS)  at  Shaw  Air  Force  Base 
(AFB),  South  Carolina  used  chat  to  support  OEF/OIF.  With  chat  they  conducted  forecast 
coordination,  tailoring,  and  dissemination  to  in-theater  units  from  one  platfonn. 

The  lack  of  weather  data  in  Iraq  complicated  forecasting  efforts,  but  with 
chat  METOC  units  at  the  CAOC,  A1  Udeid  Airbase,  Qatar  and  others  spread  throughout 
Iraq  could  collaborate  with  each  other  and  with  the  regional  forecasting  center  at  Shaw 
AFB.  The  collaboration  enabled  by  chat  allowed  them  to  develop  one  general  forecast 
for  the  entire  theater. 

US  Central  Air  Forces  Command  (USCENTAF)  METOC  used  chat  to 
provide  weather  support  to  all  four  services  in  both  the  OEF  and  OIF  theaters.  Chat  was 
used  to  communicate  with  units  in  the  field  and  discuss  weather  products.  These  units  in 
the  field  were  able  to  act  as  “eyes  forward”  feeding  weather  information  back  to 
USCENTAF  that  was  integral  to  their  product  construction.  They  found  chat  use 
provided  a  more  constant  and  reliable  flow  of  information  than  other  available  methods 
(i.e.  phone,  email).  With  chat  they  were  able  to  provide  the  best-tailored  weather 
products  to  units  because  chat  provided  access  to  most  units,  enabling  efficient,  multi¬ 
person  discussions  that  affected  large  groups  of  people.  The  time-sensitivity  of  some 
weather  products  was  met  with  chat,  which  proved  the  fastest  and  most  reliable  method 
for  their  dissemination. 

2.  J-2  Intelligence 

a.  Counterintelligence 

Members  of  the  Air  Force  Office  of  Special  Investigations  (AFOSI) 
Detachment  105,  Robins  AFB,  Georgia  provide  real  time  counterintelligence  support  in 
the  Metro-Atlanta  and  middle  Georgia  AOR.  They  used  chat  for  real-time  discussion 
about  intelligence  and  force  protection  information  with  the  Clayton  County  Sheriffs 
Office,  Georgia  Intelligence  Sharing  Analysis  Center  (GISAC)  and  other  local  law 
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enforcement  agencies.  Chat  allowed  AFOSI  personnel  to  set  up  target  areas  to  work 
sources  and  liaison  with  any  nearby  Air  Force  interests.  Chat  is  used  for  planning  and 
execution  because  of  its  ease  of  use. 

b.  National  Intelligence  Support  to  Joint  Operations 

The  US  Air  Force’s  55th  Wing  provided  national  intelligence  support  to 
OEF  and  OIF  with  their  RC-135  Rivet  Joint  (intelligence,  surveillance,  reconnaissance 
platform)  aircraft.  Chat  was  vital  for  real  time  re-tasking,  target  sharing,  and  indications 
and  warning  for  ground  elements.  More  efficient  than  voice,  chat  allowed  real-time 
connectivity  with  everybody  at  once,  including  joint  and  combined  forces  in  theater  and 
reach  back  to  various  stateside  agencies.  The  most  common  use  of  chat  was  for 
coordination  between  on-station  RC-135  Rivet  Joints,  the  CAOC,  and  strike  aircraft  and 
similar  coordination  with  ground  elements 
B.  USE  ASSESSMENT 

There  are  many  reasons  warfighters  choose  to  use  chat.  When  answering  the 
question  of  “why  chat?”  numerous  attributes  were  given.  Many  of  these  attributes  were 
synonymous,  while  some  grouped  well  into  subsets  of  others.  For  productive  discussion 
we  wanted  to  refine  the  reasons  given  for  chat  use  into  common  language,  so  we  combine 
and  reduce  them  to  the  top  five  reasons  for  use. 

1.  Faster 

Faster  applies  the  chat  users’  ability  to  request,  send,  and  receive  large  amounts  of 
information  in  real-time.  This  is  particularly  useful  for  tasking.  Tasks  sent  in  chat  are 
immediately  available  for  the  recipient  unit  to  read  once  you  send  it.  Various  members  of 
the  unit  tasked  can  immediately  read  it  and  begin  task  clarification  and  refinement  within 
their  respective  functional  areas  using  chat.  Subordinate  and  supporting  units  can  also 
monitor  these  taskings  and  begin  coordination  and  parallel  planning,  compressing  the 
planning  process  and  ultimately  the  time  to  prepare  for  mission  execution.  Tasking 
within  chat  happens  so  fast  that  some  feel  the  chain  of  command  is  bypassed  because 
very  often,  when  higher  headquarters  tasks  the  intermediate  headquarters,  the  tactical 
units  already  see  the  tasking  and  begin  working.  However;  many  units  leverage  this 
speed  to  generate  operational  tempo,  particularly  in  the  dynamic  counterinsurgent  and 
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disaster  relief  environments.  Users  report  that  chat  aids  in  speeding  up  commanders’ 
OODA  Loops  (Observe,  Orient,  Decide,  Act). 

Units  are  re -tasked  fast  with  chat.  The  use  cases  demonstrated  this:  CAS  aircraft 
in  the  air,  UAVs,  Special  Forces  teams  -  these,  and  others,  can  all  be  dynamically  tasked 
during  the  mission  because  of  the  speed  generated  with  chat. 

Faster  also  applies  to  the  transmission  time  and  turn  around  times  of  other 
systems.  There  is  no  need  to  draft  a  radio  message,  hand  it  to  the  Radio  Watch 
Supervisor,  and  wait  for  the  operator  to  send  it.  Chat  does  not  need  to  be  read  line  by  line 
like  a  radio  message  and  copied  down  at  the  other  end.  You  do  not  have  to  retransmit 
sections  of  the  message  or  read  back  sections  to  ensure  understanding  like  you  do  with 
radio.  Even  if  two  actuals  (commanders  or  staff  officers)  are  talking  to  each  other  they 
(or  somebody)  need  to  take  notes  as  grids,  times,  target  numbers  and  the  like  are  passed. 
This  is  unnecessary  with  chat,  generating  speed  and  making  it  faster. 

Finding  a  phone  number,  dialing  it,  waiting  for  an  answer,  and  then  waiting  for 
the  person  you  actually  want  to  talk  too  to  get  on  the  line  can  be  long  process.  They  may 
not  be  there  requiring  you  to  work  with  somebody  else  or  even  leave  a  message.  If  they 
are  there  you  have  to  read  grids,  targets,  etc  back  and  forth  and  copy  them  down.  Again, 
we  see  how  chat  generates  speed. 

Users  point  out  that  even  email,  file  transfer,  and  web-based  forms  are  too  slow. 
They  spend  time  looking  up  email  addresses  and  websites.  They  have  to  wait  on  the 
distant  end  to  read  their  requests  and  answer  back.  This  is  slower  than  chat.  Now 
imagine  you  need  to  send  the  information  to  ten  people  in  ten  different  units  or  agencies. 

Chat  is  fast  because  it  generates  operational  tempo.  The  increased  flow  of 
information  across  units,  functions,  operational  boundaries,  and  services  increase  speed 
in  planning  and  speed  in  execution. 

2.  Easy 

Easy  does  include  convenience,  but  easy  helps  make  chat  fast.  With  chat,  users 
have  a  list  of  who  is  in  the  room.  All  users  in  the  room  can  read  the  chat  thread  (unless 
sent  private)  so  users  do  not  need  to  look  up  email  addresses,  phone  numbers,  or  radio 
network  IDs. 
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With  many  users  in  the  room,  no  multiple  radio  calls,  emails,  or  phone  calls  need 
to  be  made.  Collaboration  is  the  norm  in  chat,  no  need  to  coordinate  it  like  white 
boarding  sessions,  conference  calls,  or  video  teleconferences.  The  ability  to  monitor 
multiple  rooms  means  that  you  can  monitor  multiple  missions  of  various  units.  Users 
feel  it  is  easy  to  build  and  maintain  their  situational  awareness  this  way. 

Chat  uses  plain  language  that  is  easier  to  converse  in  and  understand  than  radio 
procedure,  for  example.  Chat  automatically  creates  a  record  of  the  conversation  in  the 
room  that  you  can  refer  back  to  for  clarification  or  even  review  later  for  after  action 
items.  Some  chat  tools  can  log  their  conversations  so  there  is  a  record  beyond  what  is 
currently  displayed  in  the  room. 

Users  said  that  chat  was  easier  than  other  communication  systems  like  tactical 
radio  networks,  or  secure  telephones  (STU-III/STE).  Some  noted  that  is  easier  to  type  in 
Mission  Oriented  Protective  Posture  (MOPP)  gear  with  a  gas  mask  than  talk  on  a  radio  or 
phone. 

One  must  be  wary  of  the  convenience  factor,  because  chat  may  not  be  the  best 
tool  for  all  situations,  but  is  used  anyway.  For  instance,  a  request  that  a  user  needs  filled 
in  hours  or  days  is  probably  better  sent  over  email  than  in  chat.  Inundating  chat  with 
non-time  sensitive  information  creates  clutter,  confusion,  and  makes  chat  slower  and 
harder  to  use. 

3.  Availability 

This  attribute  is  a  composite  of  attributes  like  connectivity,  reliability,  stability. 
Users  found  (and  now  expect)  chat  to  be  there  when  other  C2  systems  are  not.  Further, 
they  expect  the  users  they  want  in  the  room  24  hours  a  day,  7  days  a  week. 

When  users  enter  a  chat  room,  they  not  only  expect  other  users  within  their  unit  to 
be  available,  but  “everybody  else”  worldwide.  Users  cite  chat’s  ability  to  provide  a 
collaborative  C2  capability  between  multiple  garrison  (headquarters)  units  in  the 
continental  US  and  deployed  units  worldwide  in  a  single  tool.  This  global  capability  is 
the  minimum  C2  capability  expected  by  many  warfighters  interviewed.  Further,  users 
expect  chat  to  provide  this  capability  over  SIPRNET,  high  side  (TOP  SECRET 
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networks),  and  even  on  Non-secure  Internet  Protocol  Routed  Network  (NIPRNET)  for 
coalition  disaster  relief  operations  like  JTF-Katrina  or  Operation  Unified  ASSISTANCE. 

Users  find  that  chat  is  available  when  other  C2  systems  are  not.  They  reported 
that  chat  was  the  only  form  of  communications  in  many  cases,  where  units  were  too  far 
for  voice,  and  the  available  transmission  systems  lacked  the  bandwidth  for  larger  C2 
systems.  The  geographic  dispersion  and  topography  of  Afghanistan  coupled  with  its  lack 
of  infrastructure  is  a  perfect  example.  Users  at  Forward  Operating  Bases  (FOBs)  in 
Afghanistan  during  OEF  reported  having  only  a  couple  phone  lines,  which  allowed  only 
two  concurrent  phone  conversations,  but  provided  them  the  ability  to  dial  in  with  chat 
and  have  several  concurrent  chat  sessions. 

Even  when  there  is  more  robust  transmission  systems  support,  these  systems  lack 
the  bandwidth  for  many  workstations  with  larger  C2  systems,  so  warfighters  limit  the 
number  of  these  and  use  chat  to  fill  this  capability  gap.  Many  chat  tools  use  very  little 
bandwidth  allowing  more  users  to  use  chat  than  other  C2  systems;  these  tools  avoid 
latency  and  timing  hits  on  the  network.  When  the  network  experiences  issues  and 
capabilities  degrade  (intentionally  or  not),  text-based  chat  is  the  minimum  “gotta  have” 
and  generally  available  long  after  the  other  C2  systems  have  stopped  functioning. 

Users  know  chat  will  be  available  and  reliable  and  work  that  into  their  C4  plans. 
When  deployed,  the  first  data  system  up  in  many  cases  is  chat.  Chat  is  then  used  to 
coordinate  bringing  up  and  establishing  connectivity  with  the  other  C2  systems.  Chat  is 
the  user’s  troubleshooting  tool  of  choice,  used  for  the  global  troubleshooting  of  SECRET 
and  high  side  systems  in  theater,  across  theaters,  and  even  with  contractors  stateside. 

4.  Efficient 

Users  like  how  chat  allows  them  to  send  more  data  with  far  less  expenditure  of 
time  and  effort.  For  example,  various  reports  can  be  sent  in  chat  while  the  user  continues 
to  look  at  the  Common  Operating  Picture  (COP);  map  software,  or  other  tools.  They  can 
monitor  chat  while  working  in  these  tools. 

Stated  before,  chat’s  capability  for  users  to  access  multiple  rooms  and  have 
conversations  with  multiple  people  with  no  extra  effort  is  a  capability  strongly  embraced 
by  the  warfighter.  Returning  to  sending  reports,  users  send  reports  to  large  groups  of 
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people  with  the  same  effort  it  takes  to  send  it  to  one.  While  reports  can  certainly  be  sent 
by  email,  chat  allows  other  users  who  may  not  doctrinally  need  the  report  but  are 
monitoring  the  chat  room  to  receive  it,  increasing  their  SA  at  no  additional  cost  in  time  or 
effort.  Chat  allows  users  to  be  proactive  rather  than  reactive  within  and  across 
organizations.  One  should  note  that  this  could  lead  to  the  dreaded  overreact,  or  proactive 
action  on  bad  infonnation,  and  points  to  the  need  for  good  business  rules.  Some, 
organizations,  like  USCENTAF,  have  already  developed  chat  business  rules. 

Users  like  how  chat  facilitates  understanding  with  written  text.  Time  and  effort  is 
saved  from  repeating  questions  because  you  have  it  written  before  you  -  if  information  is 
missing  users  can  identify  it  faster.  This  persistence  is  not  provided  as  efficiently  with 
other  C2  means  that  use  paper  logs  or  even  digital  methods  like  email  where  users  waste 
time  rifling  through  email  chains. 

Chat  allows  a  division  of  labor  between  units  throughout  the  world.  Preparation 
of  the  forecasts  by  the  METOC  in  the  use  cases  is  a  perfect  example.  Deployed  units 
drawing  upon  other  units  globally  can  experience  economies  of  scale. 

Technically,  the  operation  of  chat  should  breed  efficiency.  We  already  mentioned 
bandwidth  and  latency,  but  with  chat  there  is  no  retransmission  of  radio  traffic  or 
stepping  on  each,  no  repeated  phone  calls  back  and  forth.  This  creates  efficiency 
elsewhere;  reduced  radio  traffic  freeing  voice  nets  for  urgent  tactical  traffic,  phones  free 
for  when  needed,  less  load  on  email  servers. 

5.  Required 

This  attribute  is  interesting  and  foreshadows  some  of  the  issues  in  the  next  section 
on  chat  risks.  If  most  business  is  done  in  chat,  then  you  need  chat  to  do  business.  Users 
feel  that  without  chat,  their  SA  would  be  diminished  and  information  dissemination  and 
coordination  would  be  a  struggle.  In  cases  where  chat  did  become  unavailable,  users  did 
find  themselves  behind  the  power  curve  trying  to  use  other  methods  (particularly  voice) 
because  their  business  practices  had  actually  changed  (note  that  the  business  rules  did  not 
change  with  the  practices). 

Requirement  goes  beyond  capability  when  you  consider  combined  operations. 
The  HMCS  Toronto’s  experience  demonstrated  that  chat  is  required  during  coalition 
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operations,  but  not  everybody  is  always  on  the  same  chat.  The  Canadian  ship’s  call  for  a 
single  chat  was  echoed  by  Expeditionary  Strike  Group  Six  (ESG-6).  The  ESG  noted  that 
forces  under  tactical  control  of  coalition  forces  should  use  a  collation  chat  solution  (in 
this  case  CENTRIX)  where  you  would  normally  use  SIPRNET-based  chat  (ESG-6  2005). 
The  counterintelligence  use  case  demonstrated  how  a  military  unit  was  required  to  use 
chat  with  civil  authorities  to  prosecute  their  force  protection  mission. 

The  attribute  “required”  goes  back  to  the  problem  statement  of  this  paper.  There 
are  numerous  chat  tools  in  use  that  do  not  interoperate.  There  are  major  issues  during 
combined  operations.  If  we  believe,  as  users  claim,  chat  is  a  required  tool  for 
warfighting,  we  need  representation  and  program  support  to  facilitate  standardization  and 
interoperability. 

C.  CHAT  RISKS 

Chat,  like  all  military  C2  systems,  has  associated  internal  and  external  risks  that 
must  be  mitigated  to  an  acceptable  level.  The  factors  creating  risk  are  technical, 
organizational,  and  related  to  HSI.  These  risks  affect  the  baseline  Information  Assurance 
(IA)  requirements  of  confidentiality,  availability,  and  integrity  set  forth  in  DOD  Directive 
8500.1:  IA  (2002)  and  DOD  Instruction  8500.2:  IA  Implementation  (2003). 

1.  External  Risks 

The  external  risks  are  those  to  critical  infrastructure  and  parallel  to  the  generalized 
threats  to  the  GIG  and  other  national  (coalition  partners)  networks  (JCS  and  DISA  2005). 
The  peer  to  peer  aspect  (P2P)  of  chat  includes  risk,  and  was  banned  initially  before  being 
authorized  conditional  to  adherence  with  the  appropriate  IA  practices  and  Designated 
Approving  Authority  (DAA)  approval  (Wells  2004a  and  Wells  2004b).  This  does  not 
mean  the  risks  were  mitigated,  but  only  accepted. 

2.  Internal  Risks 
a.  Integrity 

Internal  risks  are  the  greatest,  with  75  -  80  percent  of  all  network  attacks 
and  loss  of  proprietary  or  classified  information  attributed  to  internal,  authorized  users 
(JCS  and  DISA  2005).  Research  has  shown  chat  use  can  lead  to  a  group  phenomenon 
termed  false  sense  of  security,  where  things  happen  to  quickly  in  virtual  collaboration  and 
lead  to  premature  decisions  (Wainfan,  Lynne  and  Davis  2004).  This  impacts  the  integrity 
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of  information  in  chat.  The  MEF  Tactical  Air  Control  Center  (TACC)  experienced 
information  integrity  issues  within  chat  rooms  during  OIF  ranging  from  erroneous  grid 
coordinates,  transposed  numbers  for  times,  and  even  an  incorrect  order  to  execute  a 
Tactical  Recovery  of  Aircraft  and  Personnel  mission  (TRAP)  (Glasgow  2003). 

b.  Confidentiality 

With  most  chat  residing  on  the  SIPRNET,  confidentiality  is  less  at  risk  by 
external  disclosure  than  by  disclosure  to  or  lack  of  disclosure  from  internal  users.  Many 
user  IDs  used  in  chat  are  functional,  making  it  difficult  to  know  who  is  really  in  the  chat 
room.  Some  consider  that  human  nature  creates  risk,  with  users  lying  about  their 
identity,  sharing  accounts,  failing  to  log  out,  account  compromise,  and  somebody  looking 
over  your  shoulder  or  even  “sniffing”  your  conversation  (JCS  and  DISA  2005). 
Malicious  software  may  be  received  and  activated  by  users  if  coming  from  a  “person” 
they  are  comfortable  with  in  chat  (JCS  and  DISA  2005). 

c.  Availability 

Availability  is  impacted  by  several  factors,  with  bandwidth  the  major 
factor  affecting  units’  ability  to  use  chat,  particularly  the  chat  capabilities  of  larger 
collaboration  suites.  During  Operation  UNIFIED  ASSISTANCE,  initial  use  of  IWS  chat 
by  deployed  METOC  teams  failed  due  to  insufficient  bandwidth,  forcing  all  units 
supporting  the  Joint  Operations  Area  Forecast  (JOAF)  to  be  switched  to  a  smaller,  less 
bandwidth  intensive  chat  tool  (Hey  2005;  Symes  2005).  A  similar  instance  happened  to 
CJTF-Haiti  METOC  personnel  from  USSOUTHCOM  using  the  DCTS  chat  software, 
which  failed  due  to  bandwidth  and  latency  shortfalls  (Kampmeyer  2004).  The  Stryker 
Combat  Teams  of  3rd  Brigade,  2ID  used  chat  in  Iraq  to  great  effect;  however,  they  too, 
suffered  bandwidth-related  availability  issues  (3rd  Brigade,  2ID  2004). 

3.  Tactical  Information  Exchange  and  Situational  Awareness 
Finally,  chat  can  actually  affect  the  units’  tactical  operations  and  situational 
awareness.  The  Combined  Anti-Armor  Teams  (CAAT)  of  Weapons  Company,  Third 
Battalion,  Fourth  Marines  struggled  to  receive  important  infonnation  in  Iraq.  Important 
tactical  infonnation,  TICs,  be  on  the  lookout  (BOLO)  reports,  friendly  troop  movements, 
and  more  was  sent  in  chat,  not  tactical  radio  networks  leaving  those  units  without  chat  out 
of  the  loop  (Butler  2005a;  2005b).  Recent  research  into  human  performance  issues  for 
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supervisory  control  of  the  Navy’s  new  Tactical  Tomahawk  missile,  reported  by 
Cummings  (2005)  made  the  unexpected  discovery  that  many  subjects  fixated  on  the  chat 
interface  and  ignored  the  task  of  retargeting  missiles  in  urgent  situations.  The  experiment 
subjects  were  repeatedly  instructed  that  retargeting  was  their  primary  mission;  however, 
they  continued  to  fixate  on  chat  answering  all  queries  before  the  retargeting  problems 
(Cummings  2005).  The  Command,  Control,  Communications,  Computers,  and  Combat 
Systems  Officer  (C50)  of  the  USS  I  WO  JIM  A,  while  standing  watch  noted  that  the 
volume  of  chat  traffic  inundated  users  with  infonnation.  This  information  deluge 
consisted  of  legitimate  traffic  and  spurious  requests  from  users  requesting  infonnation  in 
the  names  of  higher  headquarters  units.  When  the  C50  started  calling  these  users  based 
off  their  profile  information,  he  discovered  they  were  lower  ranking  personnel  collecting 
information  for  briefs  and  reports.  In  most  cases  the  information  had  already  been  passed 
and  chat  was  being  used  because  it  proved  easier  to  ask  for  the  infonnation  directly  than 
look  it  up. 

Significant  research  opportunity  exists  looking  into  managing  the  risk  of  chat  use. 
Technical  solutions  abound,  but  standardization  and  the  ability  to  integrate  cross-domain 
within  our  own  forces,  let  alone  with  coalition  partners,  remain  problems  of  policy  and 
organizational  behavior.  Organizational  change  must  be  coupled  with  HSI  research  to 
ensure  success.  Only  by  addressing  risk  as  a  dependency  of  technical,  organizational, 
and  HSI  issues  will  we  reach  an  acceptable  level  of  risk  for  the  DAA. 

D.  REQUIREMENTS 

This  thesis  developed  a  framework  for  categorizing  and  developing  future  chat 
requirements.  The  framework  consists  of  four  categories:  Functionality,  Information 
Assurance,  Scalability,  and  Interoperability. 

These  categories  were  derived  through  study  and  discourse  on  the  compiled, 
explicitly  stated  service  and  select  COCOM  and  OGA  text-based  chat  requirements.  This 
was  guided  by  the  concepts  set  forth  and  capabilities  called  for  in  the  joint  and  service 
warfighting  concepts  previously  discussed.  Appendix  D  compares  the  compiled, 
explicitly  stated  text-based  chat  requirements  by  service.  Appendix  E  compares  the 
compiled,  explicitly  stated  text-based  chat  requirements  by  COCOM  and  OGA. 
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The  focus  of  effort  to  develop  the  framework  for  considering  chat  requirements 
was  on  the  definition  of  C2  capability  gaps  filled  by  chat  and  the  identification  of 
capability  needs.  This  top  down,  systems  engineering  approach  focused  on  chat  lessons 
learned  and  stakeholders’  required  capabilities  to  broadly  define  common  requirement 
categories  and  high-level  requirements.  This  is  crucial  because  while  many  organizations 
listed  the  same  gaps  and  requirements,  they  had  very  different  ideas  of  what  those 
requirements  meant  to  them  (i.e.  a  bandwidth  austere  environment  to  the  Navy  is  very 
different  from  that  of  the  Air  Force). 

1.  Functional 

The  word  function,  as  it  regards  to  technology,  often  lacks  a  commonly 
understood  definition.  We  define  it  here  as:  “the  action  for  which  a  person  or  thing  is 
specially  fitted  or  used  or  for  which  a  thing  exists”  (Merriam-Webster  Online,  s.v. 
“function”).  This  requirements  category  addresses  those  requirements  that  contribute  to 
the  desired  core  capability  (core  function);  real-time  text-based  chat. 

A  key  question  when  considering  functional  requirements  is:  “which  requirements 
directly  contribute  to  the  core  function  and  which  requirements  add  capability  not 
required  for  the  core  function?”  For  example,  the  “participate  in  multiple  concurrent  chat 
sessions”  requirement  materially  contributes  to  the  core  function.  The  “hyperlinks”  and 
“file  transfer”  requirements,  while  useful,  are  not  required  to  achieve  the  core  function. 
This  is  evident  in  Appendices  D  and  E  by  what  requirements  the  organizations  do  or  do 
not  agree  on.  Eight  of  eight  organizations  agree  that  the  ability  to  participate  in  multiple 
concurrent  chat  sessions  is  required,  suggesting  this  is  a  bond  fide  core  requirement. 
Only  one  organization  lists  the  “hyperlinks”  requirement  and  only  two  organizations  lists 
the  “file  transfer”  requirement,  suggesting  that  these  are  not  required  to  achieve  the  core 
function  of  text-based  chat.  Table  13  lists  the  consolidated  functional  requirements  from 
Appendices  D  and  E. 
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Table  13.  Consolidated  functional  requirements 

Functional  Requirements 
(*  denotes  a  core  requirement) 

1 .  Participate  in  Multiple  Concurrent  Chat  Sessions* 

2.  Display  Each  Chat  Session  as  Separate  Window 

3.  Persistent  Rooms  &  Transitory  Rooms* 

4.  Room  Access  Configurable  by  Users 

5.  Automatic  Reconnect  &  Rejoin  Rooms* 

6.  Thread  Population/Repopulation* 

7.  Private  Chat  "Whisper"* 

8.  One-to-One  IM  (P2P) 

9.  Off-line  Messaging 

10.  User  Configured  System  Alerts 

1 1 .  Suppress  System  Event  Messages 

12.  Text  Copying* 

13.  Text  Entering* 

14.  Text  Display* 

15.  Text  Retention  in  Workspace* 

16.  Hyperlinks 

17.  Foreign  Language  Text  Translation 

18.  File  Transfer 

19.  Portal  Capable 

20.  Web  Client 

21.  Presence  Awareness/Active  Directory* 

22.  Naming  Conventions  Identify  Functional  Position* 

23.  Multiple  Naming  Conventions 

24.  Multiple  User  Types 

25.  Distribution  Group  Mgmt  System  for  Users 

26.  Date/Time  Stamp* 

27.  Chat  Logging* 

28.  User  Access  to  Chat  Logs* 

30.  Interrupt  Sessions 


Recall  the  use  assessment  section  in  this  chapter.  Under  easy,  we  noted  that  easy 
includes  convenience.  The  non-core  requirements  listed  by  stakeholders  represent 
conveniences.  Just  as  inundating  chat  with  non-time  sensitive  information  makes  chat 
slower  and  harder  to  use,  so  does  including  non-core  requirements.  These  non-core 
requirements  impact  other  reasons  warfighters  use  chat,  that  it  is:  faster,  available,  and 
efficient.  This  does  not  mean  these  non-core  requirements  are  not  valid,  but  they  must  be 
addressed  carefully  as  they  may  adversely  impact  the  reasons  chat  works  for  C2.  The 
high-level  scalability  requirements,  as  defined  by  this  research,  demonstrate  how  many  of 
these  functional  issues  may  be  addressed. 
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2.  Information  Assurance 

Information  assurance  requirements  seek  to  provide  the  capability  to  ensure  the 
integrity,  the  confidentiality,  and  the  availability  of  the  chat  tool.  These  requirements 
must  account  for,  manage,  and  mitigate  the  risks  associated  with  chat  use.  This  includes 
the  risks  discussed  in  this  thesis  applied  to  various  network  types:  secure  (SIPRNET), 
non-secure  (NIPRNET),  coalition,  and  ad-hoc  (i.e.  disaster  relief).  Table  14  lists  the 
consolidated  IA  requirements  from  Appendices  D  and  E. 


Table  14.  Consolidated  information  assurance  requirements 
Information  Assurance  Requirements 

1 .  Login  and  User  Authentication 

2.  Access  Control 

3.  User  Authentication  by  Active  Directory 

4.  Unique  ID  for  all  users  worldwide 

5.  PKI  Enabled  (DOD  Common  Access  Card) 

6.  Provide  Encryption 

7.  Network  Security  Tools 

8.  Cross  Security  Domain  Functionality 

9.  Multi-Level  Security  Operation 

10.  Cross  Security  Domain  Functionality _ 


Some  disparities  exist  between  organizations  regarding  the  IA  requirements  and 
are  annotated  in  Appendices  D  and  E.  Three  major  areas  that  differ  are:  login  and  user 
authentication  (a  derived  requirement  from  the  requirements:  access,  user  authentication 
via  active  directory,  and  PKI  enabled  from  Appendices  D  and  E),  cross  security  domain 
functionality,  and  multi-level  security  operation.  These  requirements  are  tied  very  tightly 
to  requirements  in  the  functionality  and  scalability  categories  and  a  review  of  Appendices 
D  and  E  demonstrates  the  complexity  of  this  interrelationship  and  the  variation  of  views. 
After  careful  analysis,  the  differences  were  synthesized  to  develop  three  requirements 
that  satisfy  the  disparate  ones  in  Appendices  D  and  E.  Note  the  significant  difference 
between  the  definition  of  cross  security  domain  and  multi-level  security,  which  is  a 
perfect  example  of  how  various  organizations  used  tenninology  differently  in  Appendices 
D  and  E. 
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a.  Login  and  User  Authentication 

Provide  login  and  authentication  process  with  variable  settings  using 
active  directory.  Access  to  network  is  not  consent  for  access  to  chat  system.  Two 
authentication  options:  simple  authentication  (username  and  password)  and  strong 
authentication  with  username,  password,  and  token  (DOD  Common  Access  Card). 

b.  Cross  Security  Domain  Functionality 

The  chat  tool  can  be  used  across  equivalent  level  security  domains  with 
coalition  partners,  eliminating  the  need  for  multiple,  redundant  chat  tools.  Cross  domain 
access  is  limited  to  that  required  for  communication  between  chat  tools  (i.e.  for 
SIPRNET  we  allow  access  to  the  chat  tool,  but  prevent  any  further  network  access  per 
policy). 

c.  Multi-Level  Security  Operation 

The  chat  tool  can  be  used  across  different  level  security  domains  (i.e. 
NIPRNET  chat  users  to  collaborate  with  SIPRNET  chat  users  in  a  single  tool).  This 
incurs  significantly  more  risk  than  cross  security  domain  functionality. 

3.  Scalability 

These  requirements  address  a  proposed  chat  tool’s  ability  to  rapidly  scale  in 
response  to  stakeholders’  changing  needs.  The  stakeholders  in  Appendices  D  and  E  have 
different  need  sets  based  on  missions,  organization,  and  doctrine.  Table  15  lists  the 
consolidated  scalability  requirements  from  Appendices  D  and  E. 


Table  15.  Consolidated  scalability  requirements 
Scalability  Requirements 

1.  Austere  Network  Operation 

2.  Low  Overhead  Login  Process 

3.  Use  Client  without  Server 

4.  Distributed  Architecture 

5.  Number  of  Concurrent  Chat  Sessions 

6.  Number  of  Concurrent  Users 

7.  Specified  Quality  of  Service 


The  different  need  sets  of  stakeholders  makes  reaching  agreement  regarding  these 
requirements  difficult.  The  at-sea  Navy  sails  with  the  C2  capabilities  organic  to  the  ships 

underway,  which  currently  leave  little  room  to  scale.  The  Marine  Corps’s  rapid  task 
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organization  inherent  to  the  MAGTF  results  in  very  fluid  requirements  and  C2 
architectures.  The  scalability  requirements,  as  defined  by  these  services  in  Appendices  D 
and  E,  attempt  to  address  each  service’s  needs.  After  the  reader  reviews  Appendices  D 
and  E,  ask  “do  these  requirements  address  Navy  and  Marine  needs  when  a  Marine  unit 
embarks  upon  naval  shipping?” 

We  acknowledge  the  inherent  difficulty  in  decomposing  the  requirements,  so  we 
developed  a  high-level  definition  for  each.  These  definitions  serve  as  a  common  point  of 
departure  for  future  researchers  and  stakeholders  as  they  decompose  these  requirements 
further.  They  also  address  implementation  many  of  the  non-core  functional  requirements 
discussed  earlier. 

a.  Austere  Network  Operation 

The  chat  tool  must  be  capable  of  operating  on  austere  networks  where  low 
bandwidth  and  high  latency  are  common.  Users  must  be  able  to  configure  functionality 
as  required  to  maintain  the  core  text-based  chat  capability  from  high-level  headquarters  to 
the  dismounted,  tactical  user. 

b.  Low  Overhead  Login  Process 

The  numerous  connects  and  reconnects  of  chat  users,  coupled  with 
authentication,  represent  overhead  paid  in  bandwidth.  An  efficient  login  and 
authentication  process  coupled  with  the  alternative  of  light  authentication  support  tactical 
users  in  austere  network  environments. 

c.  Use  Client  without  Server 

The  IM  functionality  of  the  chat  tool  is  sufficiently  robust  to  allow  its  use 
as  the  primary  means  of  text  communications  for  units  or  missions  with  no  chat  server 
planned  for  or  available.  Tactical  users  with  extremely  low  bandwidth  may  use  IM  to 
communicate  with  higher  headquarters,  who  may  then  in  turn  inject  the  information  into 
the  chat  system. 

d.  Distributed  Architecture 

Larger  units  would  maintain  their  own  chat  server  or  servers  that  are 
linked  together  globally.  This  distributed  architecture  supports  more  users.  Survivability 
increases  since  units  no  longer  rely  on  a  single  central  server  (server  cluster);  if  the 
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central  link  goes  down  they  continue  to  chat  on  their  local  server(s)  until  the  link  is 
restored. 

e.  Number  of  Concurrent  Chat  Sessions 

Administrators  can  set  the  maximum  number  of  concurrent  chat  sessions 
allowed  by  the  chat  clients  based  on  network  conditions  or  SA  considerations  (see  Chat 
Risks  Chapter  3).  Chat  servers  support  of  concurrent  chat  rooms  should  only  be  limited 
by  mission  requirements,  chat  protocols,  or  network  conditions.  Current  OEF/OIF 
operational  numbers  range  from  II  MEF’s  10  IRC  Servers  supporting  approximately  84 
chat  channels  to  the  350-400  chat  channels  supported  by  the  Fifth  Fleet’s  four  chat 
servers  (Shapiro  2005;  Banerjee  2005;  Heacox,  Moore,  Morrison,  and  Yturralde  2004). 

f.  Number  of  Concurrent  Users 

Chat  servers  support  of  concurrent  chat  users  should  only  be  limited  by 
mission  requirements,  chat  protocols,  or  network  conditions.  Using  the  example  from 
concurrent  chat  sessions:  numbers  of  concurrent  users  range  from  over  900  on  II  MEF’s 
servers  to  the  2500-3000  on  Fifth  Fleet’s  servers  (Shapiro  2005;  Banerjee  2005;  Heacox, 
Moore,  Morrison,  and  Yturralde  2004). 

g.  Specified  Quality  of  Service 

Chat  servers  and  clients  are  configurable  to  ensure  continued  deliverance 
of  acceptable  connectivity  and  reliability  based  on  factors  related  to  network  topology 
and  communication  transmission  systems.  Items  that  may  be  configured  include 
functionality,  the  number  of  concurrent  chat  sessions,  and  the  number  of  concurrent 
users. 

4.  Interoperability 

The  interoperability  requirements  are  reasonably  self  explanatory  and  Appendices 
D  and  E  show  that  stakeholders  citing  them  are  in  relative  agreement  on  what  they  want 
technically.  The  stakeholders  in  Appendices  D  and  E  take  a  technical  approach  to 
interoperability.  We  want  to  explore  the  other  aspects  of  interoperability  as  it  relates  to 
chat.  Even  when  everything  is  technically  perfect,  there  are  human  and  organizational 
factors  that  still  prevent  true  interoperability  of  chat.  Table  16  lists  the  consolidated 
interoperability  requirements  from  Appendices  D  and  E. 
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Table  16.  Consolidated  interoperability  requirements 
Interoperability  Requirements 

1.  DOD  Standards 

2.  Open  Standard 

3.  Multi-Platform  Clients 

4.  Interoperate  with  Existing  Collaboration 

Systems 

5.  Interoperate  With  Office  Automation  Tools 

Chat  interoperability  must  include  doctrine.  Chat  continues  to  change  the  way 
doctrine  is  executed  across  units  and  services.  Not  only  is  chat  specific  doctrine 
necessary,  but  warfighting  doctrine  must  address  chat  as  it  does  other  C2  systems.  One 
example  comes  from  the  Expeditionary  Warfare  Training  Group  Atlantic  (EWTGLANT) 
AAR  dated  15  June  2006.  Jamison  (2005)  noted  that  Battalion  Fire  Support  Coordination 
Center  Personnel  (FSCC),  Battalion  Watch  Officers,  and  Operations  Chiefs  used  chat  to 
coordinate  instead  of  doctrinal  radio  nets.  The  recommendation  was  to  formalize  chat 
into  fire  support  doctrine  (Marine  Corps  Warfighting  Publication  3-16:  Fire  Support 
Coordination  in  the  Ground  Combat  Element)  as  a  new  C2  method,  emphasizing  who 
guards,  monitors,  and  serves  as  net  control  (Jamison  2005). 

Training  is  another  part  of  chat  interoperability.  Many  chat  users  and  maintainers 
are  unaware  that  current  chat  tools  already  fulfill  some  chat  requirements  called  for  in 
Appendices  D  and  E.  The  ad  hoc  nature  of  chat  precludes  formal  training.  Chat 
experimentation  during  TW  05  proved  that  training  was  necessary  for  Universal  Chat 
client  (UCC)  users,  Multi-Level  (ML)  Chat  users,  and  Persistent  War  Room  (PWR) 
users,  to  become  aware  these  chat  tools’  features  and  understand  how  to  use  them  (TW05 
Analysis  Report  2006). 

E.  TRIDENT  WARRIOR  05 

1.  Information  Management  Chat  Experiment  Results  Analysis 

This  section  reports  the  TW05  experiment  results  and  conclusion  for  the  high- 
level  objective  “Define  Navy  FORCEnet  DOTMLPF  requirements  for  a  maritime  chat 
tool.”  The  experiment  objectives  are  listed  in  Table  17  and  the  experiment  results  by 
objective  are  listed  in  Table  18. 
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Table  17. 

TRIDENT  WARRIOR  05  Information  Management  chat  objectives 

Objective  2 

Universal  Chat  Client  (UCC)  -  Assess  the  capability  of  UCC  to  fill  the  documented  gaps 
that  currently  exist  in  current  maritime  chat  protocols  used  throughout  the  US  Navy. 

Objective  3 

Uber  Chat  -  Does  Uber  Chat  provide  functionality  that  fills  identified  gaps  in  current 
maritime  chat  protocols? 

Objective  4 

Extensible  Messaging  and  Presence  Protocol  (XMPP)  -  Does  XMPP  provide 
functionality  that  fills  identified  gaps  in  current  maritime  chat  tools? 

Objective  5 

Multi-Level  Chat  (ML  Chat)  -  Does  ML  Chat’s  unique  functionality  of  chatting  across 
two  or  more  domains  provide  the  functionality  necessary  for  Navy  Maritime  Chat? 

Objective  6 

Persistent  War  Room  (PWR)  -  Will  PWR  and  Chat  Logging  operate  over  lower 
bandwidth  subnets  and  provide  the  operator  ready  access  to  chat  functions  and  supporting 
information  as  well  as  archived  chat  logs? 

Objective  8 

Distributed  Chat  Architecture  (DCA)  -  Compare  the  proposed  DCA  (hub  and  leaf)  to 
the  current  (hub  &  spoke)  IRC  communications  architecture.  Provide  a  technical  solution 
to  operator  concerns  including  loss  of  situational  awareness,  reconnection  to  servers  after 
a  communications  outage,  intra-ship  text  chat  communications  when  off-ship 
communications  are  down. 

Table  18.  TRIDENT  WARRIOR  05  Information  Management  chat  results  by  objective 
_ _ (After:  TW05  Analysis  Report  2006) _ 


Objective  2 

Universal  Chat  Client  (UCC)  -  Uses  a  DCA  and  is  suitable  for  maritime  coalition  use 
with  a  number  of  “gap  filling”  features.  It  does  not  support  file  transfer  or  file  sharing.  It 
successfully  operated  at  low  bandwidth  with  a  P-3C  using  HF  IP. 

Objective  3 

Uber  Chat  -  Relies  on  a  DCA  and  improves  collaboration.  It  is  easy  to  use  and  backward 
compatible  with  IRC,  but  it  can  exploit  any  network  medium  to  communicate,  thus 
offering  communication  even  without  satellite  link  availability  to  the  IRC  server. 

Objective  4 

Extensible  Messaging  and  Presence  Protocol  (XMPP)  -  XMPP  functionality  was 
successfully  demonstrated  in  TW05.  The  transmission  path  used  was  not  efficient,  but 
DISA  designed  this  particular  network  architecture  for  shore  establishment  assessment. 

This  raises  the  question  about  successful  operation  of  XMPP  with  distributed 
communications  architecture,  which  has  advantages  for  Battle  Groups  at  sea. 

Objective  5 

Multi-Level  Chat  (ML  Chat)  -  Has  a  varied  feature  set,  including  the  ability  to  cross¬ 
domains,  offers  much  potential  value  for  coalition  use,  but  it  lacks  sophisticated  HSI 
attributes,  which  need  to  be  improved. 

Objective  6 

Persistent  War  Room  (PWR)  -  Easily  maintained  fleet-wide  because  it  runs  via  browser 
and  Java  applets,  vice  as  a  locally  installed  client,  and  operated  at  low  bandwidths.  HSI 
attributes  are  sound  and  the  program  contains  many  features  desirable  to  coalition 
operations. 

Objective  8 

Distributed  Chat  Architecture  (DCA)  -  The  hub  and  leaf  DCA  was  superior  to 
traditional  hub-and-spoke  architecture  because  it  improved  SA  by  preserving  chat  history; 
servers  automatically  re-connected  (reducing  loss  of  chat  history);  bandwidth  efficiency 
was  increased;  reliance  on  shore-based  servers  was  eliminated;  overall  reliability  was 
improved. 
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Table  19  lists  the  chat  tool  evaluation  results  from  TW05  by  feature. 


able  19.  Comparison  of  chat  tool  features  (From:  TW05  Analysis  Report  2006) 


Feature  Description 

MLC 

PWR 

Uber 

ucc 

XMPP 

Notes 

Supports  Time  Stamps 

Y 

Y 

Y 

Y 

Y 

Automatic  refresh  of  conversation  frame  (i.e.,  does  not  require 
clicking  refresh  button) 

Y 

Y 

Y 

Y 

Y 

Ability  to  "catch  up"  the  user  upon  reconnect,  i.e.,  "prefill"  with 
archived  messages 

N 

Y 

Y 

Y 

Y 

Uber:  Cache  catches  user  up 
automatically 

Ability  to  view  multiple  chat  rooms  at  once  without  clicking 

Y 

Y 

Y 

Y 

Y 

Alerts  user  when  a  new  messaqe  has  arrived 

Y 

Y 

Y 

Y 

Y 

Alerts  when  user  (self)  has  lost  connection 

N 

Y 

Y 

Y 

Y 

Streamlined  login  process  (login  under  one  minute) 

Y 

Y 

Y 

Y 

Y 

Logging  capability 

Y 

Y 

Y 

Y 

Y 

UCC  has  an  independent  appliation 
called  Universal  Chat  Logger 

Uber:  can  save  as  .loq  file 

Ability  to  recall  last  20  messages,  last  2  days,  etc. 

TBD 

Y 

Y 

Y 

Y 

Archieved  Log  includes  date  and  time  stamp 

Y 

Y 

Y 

Y 

Y 

Ability  to  send  to  only  one  user  (whisper  /  private  chat) 

disabled 

Y 

Y 

Y 

Y 

Supports  'Broadcast  topic'  feature  upon  joining  chat  room.  e.g.  'You 
have  joined  xyz  chatroom.  The  current  topic  is  123' 

Y 

Y 

Y 

Y 

Y 

Uber:  user  can  display  topic  by  using 
'options'  on  the  chat  window 

Supports  varying,  font  size,  style  (bold,  italics),  font  type,  and  color 

TBD 

P 

P 

P 

P 

Uber:  font  size  only 

UCC:  cannot  change  color 

Supports  collaboration  between  coalition  partners  (i.e.,  ability  for 
NATO  to  talk  to  US  Navy  or  ability  for  US  to  talk  to  mult,  countries) 

Y 

N 

N 

N 

N 

MLC  is  CDS  chat  tool.  All  others  are 
single  domain. 

Supports  separation  between  different  security  domains/enclaves 
(e.q.,  SIPRNet,  CENTRIXS,  CSS) 

Y 

N 

N 

N 

N 

Supports  languaqe  translation 

TBD 

TBD 

TBD 

TBD 

TBD 

Send  /  receive  files 

N 

Y 

Y 

N 

N 

Deselected  by  DSIR 

Ability  to  hide  timestamp  on  display  (Timestamp  still  appears  in  the 
log.) 

N 

N 

Y 

Y 

N 

Relates  to  declutter;  is  separate  from 
appearance  in  log. 

Automatic  reconnect  of  users  to  rejoin  chat  rooms  after  lost 
connection 

Y 

Y 

Y 

Y 

Y 

Stored  on  the  computer?  Or  does  user  make  up  a  username 
upon  each  login 

N 

N 

Y 

N 

N 

Uber:  stored  on  computer 

Supports  white  boarding,  voice,  and  video 

N 

Y 

N 

N 

N 

Ability  to  create  and  delete  chat  room 

Y 

Y 

Y 

Y 

Y 

2.  TW05  Conclusions  and  Recommendations 

The  complete  Navy  FORCEnet  DOTMLPF  requirements  for  a  maritime  chat  tool 
defined  by  the  TW05  experiment  results  are  listed  Appendix  F.  The  operational  impact, 
measured  impact,  and  recommendations  for  the  Military  Utility  Assessment  Board  are 
consolidated  in  the  following  figures.  Figure  5  presents  these  for  the  maritime  chat  tools 
and  Figure  6  presents  these  for  the  DCA. 
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FORCEnet  Maritime  Chat  Tools 

& 

Operational  Impact: 

•  Multiple  chat  tools  operating  with 
different  protocols  is  inefficient  to 
operational  communications. 

•  Most  of  the  chat  tools  had 
common  functionality,  but  cannot 
communicate  with  each  other. 

•  Reduced  time  and  workload  to 
prepare  and  maintain  information. 

Measured  Impact: 

•  UCC  and  Uber  are  IRC  protocol, 
operating  at  approximately  4Kpbs. 

•  Jabber  XMPP  operated  at 
approximately  10Kbps. 

•  PWR  operated  at  approximately  24 
Kbps. 

Successes  in  TW05: 

•  Automatic  communications 
reconnect  feature  of  UCC,  Uber 
and  PWR. 

•  Chat  logging  and  archive  feature 
of  UCC,  Uber  and  PWR. 

MUA  Recommendations 

•  Forward  Maritime  Chat  Tool 
Requirements  document  to 

OPNAV  and  Acquisition  to  fill 
identified  gaps  in  chat  tool 
functionality. 

•  State  as  doctrine  that  there  will  be 

•  UCC  operated  successfully  over 
HFIP  permitting  chat 
communications  with  aircraft. 

multiple  chat  technologies, 
bridged  by  UCC. 

•  Speed  acquisition  of  UCC. 

Figure  5.  TW05  Chat  Tool  OAA  Quad  (From:  Steers  2006) 


FORCEnet  Distributed  Chat  Architecture 


r 

1  •  Alternative  communications  path 
for  fleet  IRC. 

'c 


Operational  Impact: 


DCA  is  scalable. 


DCA  is  organic  to  Strike  Group 
when  operating  in  an  EHF-TIP 
environment. 


Measured  Impact: 

•  Server  to  Server  data  compressed 
over  50% 

•  75%  reduction  in  bandwidth  used  for 
IRC  chat  communications. 


MUA  Recommendations 


Successes  in  TW05: 

•  DCA  is  robust. 

•  More  bandwidth  efficient. 

•  More  reliable,  less  downtime. 

•  Eliminates  NOC/Shore  as  single 
point  of  failure  for  chat 
communications. 


•  Recommend  DCA  as  alternative  IRC  chat 
communications  path  for  immediate  near  term 
development. 

•  Continue  development  of  DCA  approach  that 
will  include  other  chat  and  application 
technologies. 

•  Use  TW05  chat  server  software. 


•  Standardize  each  AOR’s  server  software  and 
policies  to  integrate  into  a  single,  global 
network  for  SIPRNET  chat. 


Figure  6.  TW05  Distributed  Chat  Architecture  OAA  Quad  (From:  Steers  2006) 
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V.  CONCLUSION  AND  FUTURE  RESEARCH 


A.  CONCLUSION 

1.  How  is  chat  used  across  the  services  and  warfighting  functions? 

Warfighters  began  using  chat  to  solve  complex  C2  problems  across  the 
warfighting  functions.  Chat  has  since  migrated  from  a  stopgap  measure,  the  proverbial 
finger  in  the  dike,  and  become  one  of  the  main  real-time  C2  systems  used  by 
Commanders  and  operators  to  execute  all  phases  of  their  doctrinal  missions. 

This  evolution  in  chat  use  has  not  received  official  acknowledgment.  Chat 
continues  to  fall  under  the  umbrella  of  “collaboration”  that  obscures  real  usage  patterns 
and  prevents  the  appropriate  support  and  development. 

Chat  use  must  be  captured  by  doctrine  in  two  ways.  First,  chat  must  be  included 
in  the  fonnalized  joint  and  coalition  C2  doctrine  like  other  military  communications 
systems  used  for  doctrinal  mission  planning  and  execution.  Second,  warfighting  doctrine 
across  the  functional  areas  must  incorporate  chat  with  the  other  C2  systems  it  uses.  We 
must  capture  the  changes  to  warfighting  doctrine  itself  that  have  resulted  from  chat  use. 
This  goes  back  to  the  call  by  Jamison  (2005)  and  others  for  doctrine  to  reflect  the  new 
realities  of  chat. 

2.  Why  is  chat  used  across  the  services  and  warfighting  functions? 

We  explored  the  reasons  why  warfighters  use  chat.  In  a  single  sentence: 

Warfighters  use  chat  because  they  have  found  it  the  best  communications 
method  available  for  real-time,  simultaneous  communications  between 
hundreds  of  users  in  dozens  of  units  across  the  services  of  the  US,  its 
coalition  partners,  and  other  governmental  and  non-governmental 
organizations. 

3.  What  risks  are  associated  with  chat  use? 

There  are  risks  associated  with  chat  use.  The  technical  risks  are  known  and  are 
readily  mitigated  with  existing  technology  and  IA  practice.  The  human  factors  related  to 
chat  use  that  create  risk,  specifically  the  internal  risks  discussed,  must  be  addressed 
through  a  combination  of  training,  organizational  structure,  and  process.  Perhaps  the 
greatest  risk  is  if  this  research’s  call  for  doctrinal  incorporation  of  chat  goes  unheeded. 
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We  demonstrated  that  chat  is  used  for  missions  like  CAS  and  fire  support,  missions  with 
very  specific  communications  captured  in  the  doctrine  -  why  leave  chat  out? 

4.  What  are  the  high  level  chat  requirements? 

The  core  requirement  is  real-time,  text-based  chat.  We  must  acknowledge  the 
importance  of  text  based  communications,  with  chat  at  the  current  forefront,  and  provide 
the  required  support,  research,  and  development.  This  research  does  not  expect  chat  to 
look  the  same  in  10  years;  however,  we  must  support  chat  in  its  current  state  so  that  we 
may  intelligently  move  it  forward. 

Doctrine  for  chat  and  incorporating  chat  is  a  critical  requirement.  Chat  requires 
equivalent  codified  procedures  to  tactical  voice  radio  (e.g.,  over,  out,  MIJI  Reports 
(Meaconing,  Intrusion,  Jamming,  and  Interception)).  To  leave  this  to  individual  units, 
whatever  the  level,  invites  a  continuation  of  the  issues  observed  and  addressed  in  this 
research. 

A  development  approach  using  the  four  requirement  categories:  functional,  I  A, 
scalability,  and  interoperability,  will  allow  stakeholders  to  see  the  interrelationships.  This 
provides  a  framework  for  the  functional  decomposition  of  the  high-level  requirements 
and  design  of  a  workable  architecture. 

B.  FOLLOW-ON  RESEARCH 

1.  Chat  (Data)  Mining 

Modern  data  and  text  mining  tools  applied  to  chat  logs  present  unique  knowledge 
discovery  opportunities.  The  ability  to  conduct  statistical  and  trend  analysis  on  tactical 
communications  provides  doctrinal,  technical,  and  HSI  research  opportunities. 

2.  Net-Centric  Enterprise  Services  (NCES) 

The  NCES  collaborative  suite  capabilities  documents,  developed  by  DISA, 
include  a  requirement  for  a  chat  capability.  Research  into  NCES’s  ability  to  meet 
warfighter  chat  requirements  would  be  worthwhile.  Does  NCES  meet  the  requirements 
of  bandwidth  disenfranchised  units  like  a  Marine  rifle  company  commander,  an  Army 
Stryker  Brigade  Platoon  Leader,  an  underway  Navy  frigate,  or  Coast  Guard  Cutter? 

3.  Extensible  Markup  Language 

Extensible  Markup  Language  (XML)  presents  innovative  opportunities  regarding 
chat.  How  can  XML  be  used  for  data  compression,  protocol  translation,  logging,  etc? 

60 


4.  Human  Factors 

There  are  numerous  HSI  factors  regarding  chat  that  warrant  continued  research. 
How  does  chat  affect  the  “human  in  the  loop”,  the  organization  and  the  process? 

5.  Specific  Warfighting  Doctrine 

In-depth  research  into  chat  use  and  a  specific  area  of  warfighting  presents  an 
exciting  research  opportunity.  Our  successful  use  of  UAVs  is  directly  related  chat  -where 
is  chat  use  and  UAV  operations  going?  Some  recommended  topics  for  research  are: 
CAS,  fire  support  (artillery  and  Naval  Surface  Fire  Support),  and  Marine  Corps 
Distributed  Operations. 

6.  Information  Assurance 

A  researcher  could  develop  a  System  Security  Authorization  Agreement  (SSAA) 
for  chat  (general  or  a  specific  chat  tool).  The  resulting  document  would  provide  an  in- 
depth  catalog  of  all  risks  and  proposals  to  mitigate  the  risks  to  an  acceptable  level. 
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APPENDIX  A.  ACRONYMS 


ACE 


AFB 

AFOSI 

AMF 

AO 

AOR 

ASD  (Nil) 

ASOG 

AUSCANNZUKUS 

BA  JFC 
BMC2 
BOLO 
C2 

C2  JFC 
C2  JIC 
C4I 

C50 


Airborne  Command  Element  (USAF) 

Aviation  Combat  Element  -  (USMC) 

Analysis  Control  Element  -  (USAF) 

Air  Force  Base 

Air  Force  Office  of  Special  Investigations 
Afghan  Militia  Forces 
area  of  operations 
area  of  responsibility 

Office  of  the  Assistant  Secretary  of  Defense  for 

Networks  and  Information  Integration 

Air  Support  Operations  Group 

Australia,  Canada,  New  Zealand,  United  Kingdom, 

United  States 

Battlespace  Awareness  Joint  Functional  Concept 
Battlefield  Management  Command  and  Control 
be  on  the  lookout 
command  and  control 

Command  and  Control  Joint  Functional  Concept 
Command  and  Control  Joint  Integrating  Concept 
command,  control,  communications,  computers,  and 
intelligence 

Command,  Control,  Communications,  Computers, 
and  Combat  Systems  Officer  -  (US  Navy) 


CAAT 

CAOC 

CAS 

CBA 

CCJO 

CFACC 

CFLCC 

CG 

CIO 

CJCS 

CJSOTF 

CMC 

CMO 

CNA 

CNO 

COCOM 

COMFLTFORCOMINST 

COMNAVNETWARCOM 

CONOPS 


combined  anti-armor  team 

combined  air  operations  center 

close  air  support 

capabilities  based  assessment 

Capstone  Concept  for  Joint  Operations 

Combined  Force  Air  Component  Commander 

Coalition  Force  Land  Component  Command 

Commanding  General 

Chief  Information  Officer 

Chairman  of  the  Joint  Chiefs  of  Staff 

Combined  Joint  Special  Operations  Task  Force 

Commandant  of  the  Marine  Corps 

civil  military  operations 

The  Center  for  Naval  Analyses 

Chief  of  Naval  Operations 

combatant  command 

Commander  Fleet  Forces  Command  Instruction 
Commander  Naval  Network  Warfare  Command 
concept  of  operations 
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COP 

common  operational  picture 

COWAN 

coalition  wide  area  network 

CS 

civil  support 

CSAR 

combat  search  and  rescue 

CSG 

Carrier  Strike  Group 

CVN 

Multi-Purpose  Aircraft  Carrier  (Nuclear  Propulsion) 

D14 

US  Coast  Guard  District  14 

DAA 

designated  approving  authority 

DASC 

direct  air  support  center 

DCA 

distributed  chat  architecture 

DOTS 

Defense  Collaborative  Tool  Suite 

DISA 

Defense  Information  Systems  Agency 

DO 

Distributed  Operations 

DOD 

Department  of  Defense 

DOTMLPF 

Doctrine,  Organization,  Training,  Material, 
Leadership  and  Education,  Personnel  and  Facilities 

DS 

direct  support 

EMW 

Expeditionary  Maneuver  Warfare 

EP 

emergency  preparedness 

ESG 

Expeditionary  Strike  Group 

EWTGLANT 

Expeditionary  Warfare  Training  Group  Atlantic 

FAC 

forward  air  controller 

FBI 

Federal  Bureau  of  Investigation 

FCS 

Future  Combat  Systems 

FFG 

Guided  Missile  Frigate 

FFH 

Halifax  (or  City)  Class  Frigate  (Canadian) 

FM 

field  manual 

FOB 

forward  operating  base 

FRAGO 

fragmentary  order 

FSCC 

fire  support  coordination  center 

GBS 

Global  Broadcast  System 

GIG 

Global  Infonnation  Grid 

GISAC 

Georgia  Intelligence  Sharing  Analysis  Center 

GWOT 

Global  War  on  Terrorism 

HLD 

homeland  defense 

HLD  CS  JOC 

Homeland  Defense  and  Civil  Support  Joint 
Operating  Concept 

HMCS 

Her  Majesty’s  Canadian  Ship 

HSI 

human  systems  integration 

IA 

information  assurance 

IM 

information  management 

10 

information  operations 

IRC 

Internet  Relay  Chat 

ISR 

intelligence,  surveillance,  and  reconnaissance 

IWS 

Info  Workspace 
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JCIDS 

Joint  Capabilities  Integration  &  Development 
System 

JCS-J6 

Joint  Chiefs  of  Staff  J-6 

JFC 

Joint  Functional  Concept 

JIC 

Joint  Integrating  Concept 

JOAF 

Joint  Operations  Area  Forecast 

JOC 

Joint  Operational  Concept 

JOpsC 

Joint  Operations  Concepts 

JROC 

Joint  Resource  Oversight  Council 

JTF 

joint  task  force 

JV2020 

Joint  Vision  2020 

KM 

knowledge  management 

LFA 

lead  federal  agency 

LFOC 

landing  force  operation  center 

LHD 

Amphibious  Assault  Ship  (Multi-Purpose) 

LNO 

liaison  officer 

LOE 

limited  objective  experiment 

LSD 

Dock  Landing  Ship 

LZ 

landing  zone 

MAGTF 

Marine  Air  Ground  Task  Force 

MCCDC 

Marine  Corps  Combat  Development  Command 

MCOIN 

Maritime  Command  Operational  Information 
Network 

MCO  JOC 

Major  Combat  Operations  Joint  Operating  Concept 

MEDEVAC 

medical  evacuation 

MEF 

Marine  Expeditionary  Force 

METOC 

meteorological  and  oceanographic 

MEU  (SOC) 

Marine  Expeditionary  Unit  Special  Operations 
Capable 

MIO 

maritime  interdiction  operation 

ML  Chat 

Multi-Level  Chat 

MOPP 

mission  oriented  protective  posture 

MS  Chat 

Microsoft  Chat 

MSPF 

maritime  special  purpose  force 

NC  JFC 

Net-centric  Joint  Functional  Concept 

NC  JIC 

Net-centric  Joint  Integrating  Concept 

NCES 

Net-Centric  Enterprise  Services 

NCP 

Navy  Capability  Pillar 

NETCOM 

Network  Enterprise  Technology  Command  (US 
Army) 

NETWARCOM 

Naval  Network  Warfare  Command 

NIPRNET 

non-secure  internet  protocol  routed  network 

NPS 

Naval  Postgraduate  School 

NRC 

National  Response  Center 

OAG 

operational  advisory  group 

ODA 

operational  detachment- Alpha 
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OEF 

Operation  ENDURING  FREEDOM 

OEO 

Other  Expeditionary  Operations 

OGA 

other  government  agency 

OIF 

Operation  IRAQI  FREEDOM 

OMFTS 

Operational  Maneuver  From  The  Sea 

OODA 

observe,  orient,  decide,  act 

OPNAV 

Office  of  the  Chief  of  Naval  Operations 

OWS 

Operational  Weather  Squadron 

P2P 

peer  to  peer 

PAG 

Public  Affairs  Group 

PHIBGRU 

Amphibious  Group 

PHIBRON 

Amphibious  Squadron 

PUC 

personnel  under  control  (not  a  POW) 

PWR 

Persistent  War  Room 

PACSCI 

Pacific  Science  &  Engineering  Group 

RPG 

rocket  propelled  grenade 

SA 

situational  awareness 

SAR 

search  and  rescue 

SATCOM 

satellite  communications 

SD  JOG 

Strategic  Deterrence  Joint  Operating  Concept 

SIPRNET 

secure  internet  protocol  routed  network 

SITREP 

situation  report 

SPAWAR 

Space  and  Naval  Warfare  Command 

SSAA 

System  Security  Authorization  Agreement 

SSC-SD 

SPAWAR  Systems  Center  San  Diego 

STESG 

Sea  Trial  Executive  Steering  Group 

STOM 

Ship  To  Objective  Maneuver 

STE 

secure  telephone  equipment 

STU 

secure  telephone  unit 

SO  JOG 

Stability  Operations  Joint  Operating  Concept 

SOA 

Sustained  Operations  Ashore 

TACC 

tactical  air  control  center 

TACP 

tactical  air  control  party 

TIC 

troops  in  contact  report 

TRADOC 

Training  and  Doctrine  Command  (Army) 

TRAP 

tactical  recovery  of  aircraft  and  personnel 

TW04 

TRIDENT  WARRIOR  04 

TW05 

TRIDENT  WARRIOR  05 

UAV 

unmanned  aerial  vehicle 

UCC 

Universal  Chat  Client 

USCENTAF 

US  Central  Air  Forces  Command 

USCENTCOM 

US  Central  Command 

USMARFORLANT 

US  Marine  Forces  Atlantic 

USNAVCENT 

US  Naval  Forces  Central  Command 

USPACOM 

US  Pacific  Command 

USSOUTHCOM 

US  Southern  Command 
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VBSS 

VMU 

WMD-CST 

XML 

XMPP 


visit,  board,  search,  and  seizure 

Marine  Unmanned  Aerial  Squadron 

Weapons  of  Mass  Destruction  Civil  Support  Team 

Extensible  Markup  Language 

Extensible  Messaging  and  Presence  Protocol 
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APPENDIX  B.  CHAT  SURVEY  DEMOGRAPHICS 


US  Marine  Corps 


MOS 

05 

04 

03 

02 

Total 

0180:  Adjutant 

1 

1 

2 

0202:  MAGTF  Intelligence  Officer 

1 

2 

3 

0206:  Signals  Intelligence  Officer 

2 

2 

0302:  Infantry  Officer 

1 

1 

2 

0303:  Light- Armored  Vehicle  Officer 

1 

1 

0402:  Logistics  Officer 

1 

1 

0602:  C2  Systems  Officer 

3 

1 

4 

0802:  Filed  Artillery  Officer 

3 

3 

3002:  Ground  Supply  Officer 

1 

1 

6002:  Aircraft  Maintenance  Officer 

1 

1 

7202:  Air  C2  Officer 

1 

1 

7525:  Pilot  VMFA 

1 

1 

7562:  Pilot  HMH/M/L/A 

2 

2 

7566:  Pilot  HMH/M/L/A 

1 

1 

7577:  Weapons  and  Tactics  Officer 

1 

1 

7588:  NFO  (EA-6B  EWO) 

2 

2 

Total 

0 

10 

16 

2 

28 

Operational  Experience 


Operation 

Tours 

ENDURING  FREEDOM 

13 

ENDURING  FREEDOM-PHILIPPINES 

1 

IRAQI  FREEDOM  - 1 

16 

IRAQI  FREEDOM  -  II 

7 

SUBSEQUENT  IRAQI  FREEDOM  ROTATION 

2 

SOUTHERN  WATCH 

3 

UPHOLD  DEMOCRACY 

1 

ALLIED  FORCE 

1 

Billets 

Fire  Support  Coordinator,  3d  Marine  Regiment 

S-l  (Adjutant),  3d  Battalion,  3d  Marine  Regiment 

S-6  (C2  Officer),  3d  Battalion,  3d  Marine  Regiment 

S-2  (Intelligence  Officer),  2nd  Battalion,  5th  Marine  Regiment 

S-6,  2nd  Battalion,  5th  Marine  Regiment 

S-2,  6th  Marine  Regiment 

S-3  (Operations  Officer),  3d  Battalion,  6th  Marine  Regiment 

Rifle  Company  Executive  Officer,  1st  Battalion,  8th  Marine  Regiment 

S-3  A  (Assistant  Operations  Officer),  1 1th  Marine  Regiment 

Commanding  Officer  Battery  M,  3d  Battalion,  1 1th  Marines 

Supply  Officer,  1st  Combat  Engineer  Battalion 

Company  Commander,  1st  Light  Armored  Reconnaissance  Battalion 

S-3A,  3d  Radio  Battalion 

S-3,  Combat  Service  Support  Group  3 

S-3  A,  Transportation  Support  Battalion,  1st  Marine  Logistics  Group 

S-6,  Transportation  Support  Battalion,  2nd  Marine  Logistics  Group 

KC-130,  Liaison  Officer,  22nd  Marine  Expeditionary  Unit  (Special  Operations  Capable) 

S-2A  (Assistant  Intelligence  Officer),  24th  Marine  Expeditionary  Unit  (Special  Operations  Capable) 

69 


S-6A,  24th  Marine  Expeditionary  Unit  (Special  Operations  Capable) 

S-3A,  Marine  Unmanned  Aerial  Vehicle  Squadron  2 

Squadron  Pilot,  Marine  Heavy  Helicopter  Squadron  465 

Squadron  Pilot,  Marine  Medium  Helicopter  Squadron  364 

Assistant  Aircraft  Maintenance  Officer,  Marine  Air  Logistics  Squadron  4 1 

Electronic  Warfare  Department  Head,  Marine  Tactical  Electronic  Warfare  Squadron  (VMAQ)  4 

Aircraft  Maintenance  Officer  HMM-265  (REIN),  31st  Marine  Expeditionary  Unit  (Special  Operations 

Capable) 

Staff  Secretary,  2nd  Marine  Aircraft  Wing 

3rd  Radio  Battalion  Detachment  Officer  in  Charge  to  1 1th  Marine  Expeditionary  Unit  (Special  Operations 


Capable) 

TOPGUN  Instructor 

US  Air  Force 

MOS 

05 

04 

03 

02 

Total 

11  A:  C-130  Pilot 

1 

1 

12B3:  Bomber  Navigator 

1 

1 

14N3:  Intelligence  Officer 

2 

3 

5 

15W3:  Weather  Officer 

2 

4 

1 

7 

71  S3:  Special  Investigations 

Officer 

1 

1 

Total 

0 

6 

8 

1 

15 

Operational  Experience 

Operation 

Tours 

ENDURING  FREEDOM 

7 

IRAQI  FREEDOM  - 1 

8 

IRAQI  FREEDOM  -  II 

2 

SOUTHERN  WATCH 

4 

PROVIDE  COMFORT 

1 

SECURE  TOMRROW 

1 

Billets 

J3  METOC,  US  Southern  Command 
Vance  AFB 

437th  Airlift  Wing  (Special  Operations  Division) 

55th  Wing 

Air  Force  Office  of  Special  Investigations  Detachment  105 

Headquarters  Air  Force  Space  Command 

Combined  Air  Operations  Center,  A1  Udeid  Air  Base,  Qatar 

8th  Fighter  Wing,  Kunsan  Air  Base,  Republic  of  Korea 

28th  Operational  Weather  Squadron 

Graphics  Flight  Commander,  USCENTAF 

11th  Bomb  Squadron 

HQ,  2nd  Air  Force 

421st  Fighter  Squadron 

17th  Operational  Weather  Squadron 

C-32  (Boeing  757)  Pilot,  1st  Airlift  Squadron 
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US  Navy 


MOS 

05 

04 

03 

02 

Total 

1110:  Surface  Warfare  Officer 

3 

3 

1310  :  Helicopter  Pilot 

1 

1 

1600:  Information  Professional 

1 

1 

1630:  Intelligence 

1 

1 

6120:  SWOLDO 

1 

1 

Total 

1 

2 

4 

0 

7 

Operational  Experience 


Operation 

Tours 

ENDURING  FREEDOM 

1 

IRAQI  FREEDOM  - 1 

1 

JTF-Katrina 

2 

Billets 

Operations  Officer  (OpsO),  Helicopter  Anti-Submarine  Squadron  Three 
Fleet  Information  Systems  Officer,  Commander  Third  Fleet 

Command,  Control,  Communications,  Computers,  and  Combat  Officer  (C50),  USS  IWO  JIMA  (LDH-7) 
Fire  Control  Officer,  USS  STOUT  (DDG-55) 

Assistant  OpsO,  Amphibious  Squadron  Four 

Squadron  Intelligence  Officer,  Strike  Fighter  Squadron  (VFA)  146 

Navigator,  USS  CROMMELIN  (FFG-37) 


US  Army 


MOS 

05 

04 

03 

02 

Total 

18A:  Special  Forces  Officer 

1 

1 

74A:  Chemical  Officer 

1 

1 

13 A:  Field  Artillery  Officer 

1 

1 

Total 

0 

2 

1 

0 

3 

Operational  Experience 


Operation 

Tours 

ENDURING  FREEDOM 

2 

IRAQI  FREEDOM 

1 

Billets 

Special  Forces  ODA  Commander,  3d  Special  Forces  Group  (Airborne) 
2nd  Infantry  Division,  USFK,  Korea 
S-4  Officer,  41st  Field  Artillery  Brigade 
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COALITION 


Country/Service 

05 

04 

03 

02 

Total 

Canadian  Forces  (Navy) 

1 

1 

New  Zealand  (Navy)  Principle 
Warfare  Officer 

2 

2 

Total 

0 

2 

1 

0 

3 

Operational  Experience 


Operation 

Tours 

ALTAIR  (CANADIAN  OEF  PARALLEL) 

1 

UNISON  (CANADIAN  KATRINA) 

1 

Billets 

Combat  Officer,  HMCS  TORONTO  (FFH-333) 

New  Zealand  Maritime  Operations  Staff 

Joint  CIS  Plans  -  Maritime  (J65M),  Head  Quarters  Joint  Forces  New  Zealand 
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APPENDIX  C.  CHAT  SURVEY  EXAMPLE 


OPERATIONAL  CHAT  REQUIREMENTS 

Captain  Bryan  A.  Eovito,  USMC 

Joint  Command,  Control,  Communications,  Computers,  and  Intelligence  (JC4I) 

Graduate  School  of  Operational  &  Information  Sciences  (GSOIS) 

Naval  Postgraduate  School 
1  University  Circle 
Monterey,  CA  93943 

NIPRNET:  baeovito@nps.edu 

Purpose 

This  data  call  seeks  to  generate  operational,  user-level  data  concerning  text-based  chat 
usage. 

Instructions 


This  data  call  has  two  parts: 

1 .  Respondent  information. 

2.  Twelve  questions.  A  series  of  questions  designed  to  capture  respondent  experience. 
When  answering,  use  specific  examples.  Examples  may  be  drawn  from  operational  and 
exercise  experiences. 

*Respondents  may  add  additional  comments,  inputs,  etc  at  the  end  of  the  document; 
however,  please  ensure  they  are  clearly  defined. 

Respondent  Information 

1.  Rank: 

2.  Service  (&  Country): 

3.  MOS  (Warfare  Designator): 

4.  Last  billet  and  unit: 

5.  Operations  participated  in: 
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Questions 

Respond  with  specific  examples.  Explain: 

•  What  chat  tool(s)  were  used 

•  What  services,  coalition  partners,  or  other  organizations  were  involved  in  the 
chat 

•  How  it  affected  your  ability  to  perform  the  task 

•  Why  chat  was  used  rather  than  another  form  of 
communication/collaboration. 

•  Specify  if  you  used  chat  for  PLANNING,  EXECUTION,  or  BOTH 

•  Consider  both  operational  and  exercise  experience 


1.  Have  you  used  chat  during  the  Marine  Corps  Planning  Process  (MCPP)  or  Rapid 
Response  Planning  Process  (R2P2)/Crisis  Action  Planning  (CAP)? 

2.  Have  you  used  chat  for  target  planning  and/or  strike  execution? 

3 .  Have  you  used  chat  for  tasking  intelligence  assets?  Have  you  used  chat  to  collect  or 
disseminate  intelligence? 

4.  Have  you  used  chat  for  operational  execution  (tasking,  coordinating,  passing 
prowords,  etc)?  Treat  each  independently  and  provide  examples. 

5.  Have  you  used  chat  for  logistical  planning  and/or  execution? 

6.  Have  you  used  chat  for  cross  boundary  coordination  (same  service,  joint  forces,  or 
coalition  forces)? 

7.  Have  you  used  chat  for  C2/C4ISR  Systems  Installation,  Operation,  and  Maintenance 
(IOM)  to  include  troubleshooting? 

8.  Have  you  used  chat  to  plan,  request,  or  coordinate  Search  and  Rescue  (SAR)  or 
MEDEVAC? 

9.  Have  you  used  chat  to  plan,  task,  coordinate,  or  execute  Combat  Assault  Support  or 
Close  Air  Support? 

10.  Have  you  used  chat  for  supporting  arms  coordination,  fire  plan  development,  or 
execution? 
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1 1 .  Have  you  used  chat  for  planning,  coordinating,  or  executing  Civil  Military 
Operations? 

12.  Have  you  used  chat  for  any  tasks  not  listed  here? 
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APPENDIX  D.  SERVICE  CHAT  REQUIREMENTS 

COMPARISON 


SERVICE  TEXT-BASED  CHAT  REQUIREMENTS  COMPARISON 

Requirement 

USN 

USMC 

USA 

USAF 

FUNCTIONALITY 

Participate  in  Multiple 
Concurrent  Chat 
Sessions 

X  (Tile,  minimum 

10;  participating  is 
monitoring  & 
sending;  tactical 
users  treat  as  radio) 

X  (Open,  join,  and 
chat  simultaneously) 

X 

X 

Persistent  Rooms  & 
Transitory  Rooms 

X  (Log  both  types; 
persistent  remains 
when  empty, 
transitory  ends  when 
last  user  leaves) 

X  (invite  to  session 
on  ad  hoc  basis; 
administrator  should 
be  able  to  promote  ad 
hoc  to  persistent) 

X  (persistent  and  ad 
hoc  conferences) 

Room  Access 
Configurable  by  Users 

X  (Public,  private, 
hidden;  related  to 
login  overhead 
issues;  assign  user(s) 
as  moderators) 

X  (Moderator  to 
control  and  manage 
chat  sessions) 

X  (admit,  deny, 
remove  users) 

Automatic  Reconnect 
&  Rejoin  Rooms 

X 

Thread 

Population/Repopulati 

on 

X  (User  controlled, 
select  portion  of  log 
to  repopulate) 

X  (catch-up  feature 
for  late  entry) 

Private  Chat 
“Whisper” 

X  (Logging  of  these 
configurable  by  user) 

One-to-One  IM  (P2P) 

X 

User  Configured 

System  Alerts 

X  (Keyword 
configuration; 
audio/visual  alarm; 

user 

connect/disconnect) 

Suppress  System 

Event  Messages 

X 

(Connect/disconnect 
of  users  not  shown  in 
thread;  configurable 
alerts  for  specific 
user 

connect/disconnect) 

X  (systems  events  not 
in  text  channel  but 
system  control 
channel) 

Naming  Conventions 
Identify  Functional 
Position 

X  (Functional  name 
stays  logged  in,  user 
attached  changes) 

X  (view  identity  of 
participants) 

X 

Multiple  Naming 
Conventions 

X  (Varies  with  scope 
of  room) 

Multiple  User  Types 

X  (moderator, 
participant,  viewer) 
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Date/Time  Stamp 

X  (Connect, 
disconnect, 
messages) 

X 

X  (For  auditing) 

Chat  Logging 

X  (Central  on  server; 
user  searchable) 

X  (save  and  archive) 

X  (save  chat  and  IM 
content) 

X  (For  auditing) 

User  Access  to  Chat 
Logs 

X  (User  searchable 
from  Chat  Logging) 

D  (Searches  and 
queries  of  logged 
data) 

X 

INFORMATION  ASSURANCE 

Access  control 

X(members-only, 
password-only,  and 
invite-only) 

PKI  Enabled  (DOD 
CAC) 

X 

User  authentication  via 
Active  Directory  and 
LDAP  ver3 

X 

Unique  ID  for  all  users 
worldwide 

X 

Provide  Encryption 

X  (DES,  3DES,  and 
AES  encryption  (up 
to  256-bit)) 

Multi-Level  Security 
Operation 

D 

SCALABILITY 

Austere  N  etwork 
Operation 

X  (100  bps  per 
user/room;  tactical 
platforms  <10Kbps; 
satellite  latency) 

D  (EPLRS;  I  MEF 
IRC  Implementation) 

X  (<56kbps, 
<256kbps, 

<  1024kbps) 

X(2.4  Kbps) 

Low  Overhead  Login 
Process 

X  (lightweight 
authentication  or 
optional) 

Use  Client  Without 
Server 

X  (P2P  between 
clients  -  SOC  model) 

Distributed 

Architecture 

X  (Ships  have 
organic  capability) 

X  (operate  globally  & 
federated) 

#  Concurrent  Chat 
Sessions 

X  (40  threshold) 

#  Concurrent  Users 

X  (2000  threshold) 

X  (<25,  <50,  <100) 

X  (Single 
session=500+; 
federated=500,000+) 

Specified  Quality  of 
Service 

X  (Response  time, 
reliability,  latency  - 
all  TBD) 

INTEROPERABILITY 

DOD  Standards 

X 

X  (based  on 
standards  by  any 
recognized  standards 
body) 

Multi-Platform  Clients 

X  (servers:  Solaris, 
Linux,  BSD,  IBM, 

X  (1.  Applications 
(Win32,  UNIX) 
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and  Windows  server 

8;  clients:  (WinX, 
Linux,  Windows  CE, 
and  MacOS)  mobile 
devices/handhelds) 

2.  Applets  (Java, 

VM) 

3.  Web  Browser- 

only) 

Interoperate  with 
Existing  Collaboration 
Systems 

X  (188/220  interface 
[radio 

communications]  D- 
DACTs) 

X  (Interoperate  with 
existing  USAF  IM, 
Chat,  and  Presence 
systems:  1. 
InfoWorkSpace,  2. 
DCTS  (Envoke),  3. 
mIRC  (IRC), 

4.  Sametime 
(SIMPLE)) 

Interoperate  With 

Office  Automation 

Tools 

X 

Sources: 

Banerjee,  Sunoy  N.,  and  John  A.  Bentrup.  2002.  Proposed  NETWARCOM  Guidance:  The 
effective  Use  of  Chat.  Alexandria:  Center  for  Naval  Analyses.  CRM  D0006071.A3/Revised. 

Banerjee,  Sunoy  N.,  and  John  A.  Bentrup.  2003.  Fleet  Chat  Requirements.  Alexandria:  Center  for 
Naval  Analyses.  CME  D0008468.A1. 

Bentrup,  John  A.,  Sunoy  N.  Banerjee,  Aaron  R.  Baldwin,  and  Carl  V.  Kimble.  2005.  Distributed 
Internet  Relay  Chat  Architecture.  Alexandria:  Center  for  Naval  Analyses.  CRM  D0010253.A1/Final. 

Boettcher,  Diane,  SRA,  Defense  Information  Systems  Agency.  “Text-based  Chat  Way  Ahead 
Update  28  March  2005.”  (Presentation  at  SPAWAR  Systems  Center  2005  IRC  Chat  Conference),  San 
Diego,  8  June  2005. 

Catanzaro,  Jean  Ph.D.  2005.  Compiled  Features  of  Chat  Client  Technologies  San  Diego:  Pacific 
Science  and  Engineering  Group,  Inc. 

Catanzaro,  Jean  Ph.D.,  John  Gwynne,  Ph.D.,  and  Craig  Mitchell,  Ph.D.  2005.  Usability  of  Chat  in 
the  Maritime  Coalition  Environment:  Empirical  Findings  from  a  Limited  Objective  Experiment  for  Trident 
Warrior  2005.  2005.  San  Diego:  Pacific  Science  and  Engineering  Group,  Inc. 

Catanzaro,  Jean  Ph.D.,  John  Gwynne,  Ph.D.,  and  Samuel  Landau,  Ph.D.,  2005.  Compiled  Chat 
User  Requirements.  San  Diego:  Pacific  Science  and  Engineering  Group,  Inc. 

Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS).  J6.  2004.  “Architecture  Description  Collaboration 
Capabilities  Version  1.1  (DRAFT).”  Available  online;  Internet;  accessed  15  Oct  2005. 

Collaboration  Requirements  United  States  Joint  Forces  Command  (DRAFT).  2005.  Prepared  by 
the  Standing  Joint  Force  Headquarters  Directorate  and  The  Collaboration  Information  Environment 
Management  Office.  Norfolk:  U.S.  Joint  Forces  Command. 

Concept  of  Operations  for  Command  and  Control  (C2)  Constellation.  2003.  Langley  AFB 
Virginia:  AFC2ISRC/CX.  Electronic:  C2  Constellation  CONOPS  V8.doc,  Microsoft  Word  document. 

Conversion  of  the  Joint  Command  and  Control  (JC2)  Capability  Operational  Requirements 
Document  (ORD)  to  a  Capability  Development  Document  (CDD)  DRAFT  version  2.2.  2004.  Department 
of  Defense.  Washington,  D.C.  Available  online;  Internet;  accessed  15  Oct  2005. 
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Defense  Information  Systems  Agency.  “Capability  Development  Document  (CDD)  for  Net- 
Centric  Enterprise  Services  (NCES),  Increment:  1  ACAT  IAM,  Prepared  for  Milestone  B  Decision,  Draft 
Version:  0.9.0.  2005.”  Available  online;  Internet;  accessed  15  Oct  2005. 

Defense  Information  Systems  Agency.  “Next  Generation  Collaboration  Service  -  Pilot  Project 
Plan  21  January.”  Available  online;  Internet;  accessed  15  Oct  2005. 

Draft  Chat  Requirements.  2005.  Electronic:  NAVAL  Jun2005  Draft  Chat  Requirements.doc, 
Microsoft  Word  Document. 

“Draft  Chat  Requirements  (USMC  contractor  review  of  USN  chat  requirements  with  comments 
annotated  electronically  in  document).”  2005.  Electronic:  Jan  05  Draft  Chat  requirements  -  comments 
davismr.doc,  Microsoft  Word  document. 

Duffy,  LorRaine.  2005.  “Internet  Relay  Chat  (IRC):  How  a  Grassroots  Technology  became  an 
Integral  Part  of  Operational  Command  and  Control.”  Submitted  for  publication  in  SSC  Biennial  Review. 

FORCEnet  A  Functional  Concept  for  the  21st  Century.  2005.  Washington:  Offices  of  the  Chief  of 
Naval  Operations  and  the  Commandant  of  the  Marine  Corps. 

Heacox,  Nancy,  Ronald  A.  Moore,  Jeffrey  G.  Morrison,  and  Rey  F.  Yturralde.  2004.  Real-time 
Online  Communications:  “Chat”  Use  in  Navy  Operations.  San  Diego:  Pacific  Science  and  Engineering 
Group,  Inc. 

Headquarters  Department  of  the  Army.  2004.  Army  Communications  Guidance  2004.  Available  at 
Army  Knowledge  Online;  Internet;  accessed  20  Sep  2005. 

Headquarters  United  States  Marine  Corps.  Command,  Control,  Communications,  Computers,  and 
Intelligence.  2005.  “Functional  Requirements  for  Collaboration  Tools.”  Electronic:  Collaboration 
Requirements-Functional-Nov2004.xls,  Microsoft  Excel  spreadsheet. 

Herbert,  MAJ  Lloyd,  SAF/XCISS.  2005.  “USAF  IM/Chat  Requirements  Summary.”  United  States 
Air  Force.  Electronic:  Chat  Requirements  Summary.doc,  Microsoft  Word  document. 

Inman,  Jay  and  Mike  McHargue.  2005.  Futures:  Identity’  Management,  SPS  and  Collaboration. 
Available  online;  Internet;  accessed  15  Oct  2005. 

Kies,  LtCol,  Micheal  A.,  II  MEF  IMO.  FW:  Collaboration  Tool  Needs  for  USMC?  [Online], 
Email  to  Captain  Bryan  A.  Eovito,  10  August  2005. 

Kovacevich,  MAJ  Mark,  US  Army  Forces  Command  G6/JWSD  Collaboration  Section  Leader 
DCTS  Project  Officer.  2005.  “Capability  Development  Document  for  Net-Centric  Enterprise  Services  - 
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Electronic:  FORSCOM. ppt,  Microsoft  Power  Point  Presentation. 
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APPENDIX  E.  SELECT  COMBATANT  COMMAND  AND 
DEFENSE  INFORMATION  SYSTEMS  AGENCY  TEXT-BASED 
CHAT  REQUIREMENTS  COMPARISON 


SELECT  COMBATANT  COMMAND  AND  DEFENSE 
INFORMATION  SYSTEMS  AGENCY  TEXT-BASED  CHAT 
REQUIREMENTS  COMPARISON 

Requirement 

JFCOM 

CENTCOM 

NORTHCOM 

DISA 

FUNCTIONALITY 

Participate  in 

Multiple  Concurrent 
Chat  Sessions 

X  (Monitor  & 
participate) 

X  (Multiple 
Simultaneous 
Chat  Sessions 
Viewable) 

X  (Ability  to 
simultaneously 
view  multiple 
rooms  on  monitor) 

X  (Multiple  Room 
View) 

Display  Each  Chat 
Session  as  Separate 
Window 

X 

X  (Multiple  Room 
View) 

Persistent  Rooms  & 
Transitory  Rooms 

X  (Chat  room 
remains  in 
existence  even  is 
all  participants 
leave) 

X  (Persistent 
rooms) 

Room  Access 
Configurable  by 

Users 

X(users  add 
users  &  invite 
users) 

X  (Quick  and  easy 
for  new  users 
requiring 
immediate  access; 
includes  new  user 
registration) 

Automatic 

Reconnect  &  Rejoin 
Rooms 

X  (Reconnect) 

Thread 

Population/Repopula 

tion 

X  (Ability  to  re¬ 
call  text 
messages  for  a 
break  in 
connectivity) 

X  (Message 
history  on 
command) 

One-to-One  IM 
(P2P) 

X  (Must  provide  a 
controlled  text- 
based  chat 
environment;  tool 
should  queue 
messages  for 
offline  users) 

X  (From 

bandwidth/COCO 
M  statement) 

Off-line  Messaging 

X 

User  Configured 
System  Alerts 

X  (User  manually 
send  targeted  or 
broadcast  alerts  to 
other  users,  the  tool 
should 

automatically 
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notify  user  based 
on  criteria  that  the 
user  has 
determined  (e.g. 
highlighted  words)) 

Text  Copying 

X  (Copy  & 
paste  text  from 

all 

applications) 

X 

Text  Entering 

X  (Ability  to 
enter  original 
text) 

Text  Display 

X 

(Sequentially 

& 

continuously 
displayed; 
intuitively 
identify  text 
provider;  users 
can  scroll 
through  text  of 
entire  session) 

Text  Retention  in 
Workspace 

X  (Text 
remains  in 
workspace 
until  removed 
by  selected 
user(s)) 

Hyperlinks 

X  (URLS 
recognized  and 
active  within  chat 
text) 

Interrupt  Sessions 

X  (Session 
managers  and 
admins  can 
interrupt  active 
channels  as 
needed 

Foreign  Language 
Text  Translation 

X  (Text  & 
data) 

X 

File  Transfer 

X  (File  Transfer 
Capabilities) 

X 

Portal  Capable 

X  (Capable  of 
running  in  a 
portal 

environment) 

Web  Client 

X  (Web  capable 
client) 

X  (Web/Flash 
client) 

Presence  Awareness 

X  (User  ability  to 
see  who  is  online) 

X 

Naming 

Conventions 

Identify  Functional 
Position 

X 

X 
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Multiple  Naming 
Conventions 

X  (Identify 
user  by 
date/time 
stamp,  name, 
functional 
name) 

X  (Role  based 
users  have  the 
ability  to  “turn  off’ 
role  and  become 
themselves  or 
another  role  based 
name) 

Distribution  Group 
Mgmt  System  for 
Users 

X  (On/off 
feature  to 
select  user 
participants) 

Date/Time  Stamp 

X 

X(Date/Time 
Stamp  on  all 
Messages) 

X 

Chat  Logging 

X  (RECORD; 
retrieve  & 
playback) 

X  (Server  should 
log  all  chat  activity 
for  future  retrieval) 

X  (Server  side 
logging) 

User  Access  to  Chat 
Logs 

X 

X  (Searchable; 
User  optional 
logging  of  chat 
activity  in 
monitored 
channels) 

INFORMATION  ASSURANCE 

Access  control 

X  (Use  Active 
Directory  for 
authentication) 

X  (Secure  single 
sign-on  and 
seamless  user 
authentication 

X  (XMPP) 

Provide  Encryption 

X  (integration  with 
industry  standard 
SSL  encryption) 

X  (XMPP) 

Network  Security 
Tools 

X  (Meet  current 
security 
requirements) 

X  (compatibility 
with  firewalls  and 
proxy  servers) 

Cross  Security 
Domain 

Functionality 

X  (Capable  of 
sending 
messages 
between 
different 
networks  of 
various  security) 

X 

SCALABILITY 

Austere  Network 
Operation 

X  (Useable  by 
low  bandwidth 
users) 

X  (Low-bandwidth 
Chat/IM  capability 
identified  by 
COCOMs  as 
lowest  common 
denominator, 
“gotta  have” 
collaboration 
service 

INTEROPERABILITY 
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DOD  Standards 

X  (Interoperable 
with  approved 
DOD  network 
configurations  and 
applications  - 
Plug-n-Play) 

Open  Standard 

X  (Open  protocol; 
industry  support; 
future 

development) 

Multi-Platform 

Clients 

X  (User  accessible 
on  any  device; 
requires  no  client- 
software  download; 
works  with 
multiple  client 
platforms;  allows 
easy 

communication 
across  the  same 
system 

Interoperate  with 
Existing 

Collaboration 

Systems 

X  (Interoperable 
with  Current 
Chat 

Infrastructure  - 
Native  or  Bridge 
Capable) 

X  (Must  allow 
communication 
with  mission 
partners  (i.e. 
DHS)) 

X 

Sources: 


Boettcher,  Diane,  SRA,  Defense  Information  Systems  Agency.  “Text -based  Chat  Way  Ahead 
Update  28  March  2005.”  (Presentation  at  SPAWAR  Systems  Center  2005  IRC  Chat  Conference),  San 
Diego,  8  June  2005. 

U.S.  Joint  Forces  Command.  Standing  Joint  Force  Headquarters  Directorate  and  the  Collaboration 
Information  Environment  Management  Office.  “Collaboration  Requirements  United  States  Joint  Forces 
Command  (DRAFT).”  2005.  Norfolk:  U.S.  Joint  Forces  Command. 

Defense  Information  Systems  Agency.  “Next  Generation  Collaboration  Service  -  Pilot  Project 
Plan  21  January.”  Available  online;  Internet;  accessed  15  Oct  2005. 

Moore,  Mr.  Douglas  R.,  CCJ6-DXC  Contractor,  LMIT.  “United  States  Central  Command  (US 
CENTCOM)  Text  Chat  Capabilities.”  2005.  (Presentation  at  SPAWAR  Systems  Center  2005  IRC  Chat 
Conference),  San  Diego,  8  June  2005. 

Ritchie,  Mr.  Jody,  Collaboration  Project  Lead.  2005.  “NORAD-USNORTHCOM  (N-NC) 
Synchronous  Collaboration.”  (Presentation  at  SPAWAR  Systems  Center  2005  IRC  Chat  Conference),  San 
Diego,  7  June  2005. 

U.S.  Northern  Command  and  North  American  Aerospace  Defense  Command.  “NIPRNET 
Enteiprise  Chat  Solution  (DRAFT).”  2006.  IT  Request  Number:  05-0946. 
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APPENDIX  F.  TRIDENT  WARRIOR  05  MARITIME  CHAT 

REQUIREMENTS 


TRIDENT  WARRIOR  05  Maritime  Chat  Requirements  (From:  Steers  2006a) 


Text  Chat  Requirements  By  Category 

Shall  Should  Notes 

I.  DOD/Industry  Standardization 

Open  Standard 

X 

Open  Architecture 

X 

Service  Oriented  Architecture 

X 

II.  Security 

Comply  with  current  DOD  security 
requirements 

X 

Comply  with  DOD  IT  Standards 

Registry  (DISR) 

X 

ITT.  Communications  Scalability 

Operate  in  Ethernet,  UHF  and  HF 
communications  mediums 
Fow  Bandwidth 
Fow  Data  Rate 
High  Fatency 

Operate  globally  in  a  federated  network 
Operate  on  local,  disconnected,  and 
closed  network 

Support  Cross  Domain  or  Multi- 
National  solution 

Support  Distributed  Server  Architecture 
Support  UNIX  and  Windows 
interoperability 

Fink  chat  tool  functionality  to 
bandwidth  availability 

Accommodate  not  less  than  1000+ 
participants  per  chat  session 


X 

X 

X 

X 

X 

X 

Tactical  environment 

Must  support  CDS  or  Multi- 

X 

National  Information  Sharing 
solution 

X 

X 

Maintain  core  text  chat 
^  capability  at  very  low 

bandwidth  levels  (less  than  2.4 
Kbps) 

X 
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Instant  Messaging  (IM)  capable 


Voice  over  IP  (VoIP)  chat  capable 


Should  accommodate 
functionality,  but  not  at  the 
X  expense  of  maintaining  a  text 
communication  capability  at 
low  bandwidth  requirement. 
Should  accommodate 
functionality,  but  not  at  the 
X  expense  of  maintaining  a  text 
communication  capability  at 
low  bandwidth  requirement. 


IV.  Communications  Disruptions 

Intermittent  Connectivity  -  support 
multiple  server  disconnects 

X 

Default  value  can  be  modified 

Limited  number  of  reconnect  attempts 

X 

by  operator  up  to  a 
predetermined  maximum 

Selectable  interval  (time)  for 
reconnection  attempt 

X 

Provides  tactical  functionality 

Chat  tool  is  operable  after 
communications  disruption  and  sends 
text  upon  reconnection 

X 

V.  Functionality 

Time  stamp  messages 
Date  stamp  messages 
Time  stamp  members  joining  and 
leaving  rooms 

Date  stamp  members  joining  and 
leaving  rooms 

Automatic  download  of  logs  on  joining 
(pre-fill  chat  rooms  with  past  messages) 
Maintain  chat  history  during  network 
outages 

Maintain  screen  contents  upon 
reconnect 

Support  visual  alerts 
Support  audio  alerts 


X 

X 

X 

X 

X 

X 

X 

X 

X 


Quantity  of  pre-fill  is  selectable 
by  operator 


Visual  and/or  Audio  notification  of 
communication  interruption  to  operator 
Chat  Client  remains  operable  during 
communications  interruption 
Automatic  rejoining  of  chat  rooms  upon 
communications  restoration 
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Alert  operator  for  new  messages 

Provide  audio/visual  alerts  to  operator 

X 

X 

for  selected  key  words 

Ability  to  "cut  and  paste"  text  between 
multiple  chat  rooms 

X 

Support  varying  font  size,  font  type, 
style  (bold,  italics)  and  color 

X 

Font  Size  (from  9  to  20),  type 
(Ariel,  Times  New  Roman  or 
Courier  New). 

Operator  selectable  (on  /  off) 

Viewing  of  member  entry  /  exit 

X 

configuration  to  reduce  screen 
clutter 

Messages  can  be  transmitted  by  hitting 
"Enter"  key  in  addition  to  clicking 
"Send"  button  with  mouse 

X 

VI.  Chat  Sessions  /  Rooms 

Public  chat  rooms 

X 

Users  must  be  able  to  freely 
enter  vice  "invite  only" 

Private  chat  rooms 

X 

Pennanent  rooms  (functional) 

X 

Rooms  need  to  remain  when 
users  disconnect 

Temporary  rooms 

X 

Rooms  dissolve  after  last 
member  leaves 

Limit  access  to  private  chat  rooms 

Allow  user  to  join  or  leave  chat  room  at 
will 

Monitor  multiple  chat  rooms 

Participate  in  multiple  chat  rooms 

X 

X 

X 

X 

Not  less  than  10 

simultaneously 

Operator  selectable 

Visual  "tiling"  of  multiple  chat  rooms 

X 

configuration,  not  less  than  10 

rooms 

Resize  chat  room  windows 

X 

Support  multiple  layouts  of  chat  rooms 
(tabbed,  tiled,  etc) 

X 

Ability  to  search  for  chat  rooms  within  a 
certain  category 

X 

VII.  Logging  /  Archiving 

Automatic  logging 

X 

Logging  is  not  optional  at 
server  or  workstation 

Log  all  (server  &  room)  messages  at  ^ 

server 

Log  public  chat  room  conversations  X 

Log  private  chat  room  conversations  X 

89 


Log  pennanent  chat  room  conversation 

X 

Log  temporary  chat  room  conversation 

X 

Automatic  sending  of  stored  chat  upon 

X 

communications  restoration 

Logs  are  retrievable 

X 

Logs  are  searchable 

X 

VIII.  User  Login  and  Identification 

Streamline  login  process  X 

Configure  to  startup  chat  client 
automatically  upon  login/reboot 
Configure  to  automatically  join  a  user 
specified  set  of  chat  rooms  upon  login 

Support  the  use  of  functional  title 

(IKETAO)  and  user  name  (LCDR  John  X 

Smith) 


Lowest  possible  connection 
overhead 

X  Selectable  by  operator 

X 

For  Permanent  rooms  provide 
the  ability  for  watchstanders  to 
change  name  with  function 
without  having  to  log  out  and 
in.  This  maintains  continuity  of 
chat  session 
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